20 Jan
2012
20 Jan
'12
1:55 a.m.
On Thursday 19 January 2012 05:55:21 pm Bruce Dubbs wrote:
Yes but I don't need to do that. I only have one app that needs qt4. I'll
address it when and if I need more apps that need qt4 but for now one is all
I need.
I use to have qt3 and qt4 installed into /usr. That is the way it was when I
first built TDE. I changed it so I would have to muck around with the paths.
The way it is now I just build and don't have to mess with the paths.
Also since tde is the only thing that I have that uses qt3 putting it
into /usr/local means that tde and qt3 is in one place. Empty /usr/local and
TDE and company is gone. Not that I would do that, again pacman -Rsn tde
does that automatically.
Yes that is why I call it my play ground
echo $PATH
/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl
pkg-config is configured to look into /usr/lib and /usr/local/lib/config
ld is also configured to look at /lib and /usr/local/lib
So I am good to go/play with tde. Minimum fuss.
If I really make a mess I can just empty /usr/local.
Yes I have read that. In fact I have a pdf document.
Yes as it should be
Well I have a couple of choices put 3.5.13 into /usr put 3.5.14
into /usr/local fixup PATH and I can run either. Also see above.
Baho Utot wrote:
I have a plan.
The package manager (pacman) I use handles that with ease and does this
without any major trouble. If you really want a challenge upgrade glibc in
place across major version not minor version, with pacman it's easy.
Rebuilding as LFS does it is one way but pacman can handle it on a running
machine properly. Yes I know you need to rebuild everything, that easy too
with pacman. Bump release numbers and do a rebuild on the packge repo and
you're good to go. In fact that is what I am currently doing with LFS,
building it with pacman. Then I don't need to rebuild the system only what
is changed. Any way I digress.....
Well for example I can remove 3.5.13 that is installed into /usr. Then
install 3.5.14 into /usr. If it doesn't work I can down grade By simply
pacman -Rsn;pacman -S tde-3.5.13 and all is well. Or I can do as you have
see way below.
Or I can pacman -Syu tde which would upgrade TDE in place to 3.5.14 and again
if it is broken I can do pacman -S tde-3.5.13 and it will down grade all the
packages to 3.5.13 and all is well and I am back where I started. The only
thing that is gone is the time.
I try to keep to FHS as much as possible so I
don't incur this type of
wrath from pkg-config and the gnu tool chain. To say nothing of actually
ruining the beast when you've finished getting it to build.
This why I put TDE into /usr so the build environment doesn't cause me
gas and bloating... and I know it will run when I get the beast
installed.
And what happens if you are using that version of Trinity in /usr and
want to test the latest. You write over your working executable or
library with one that may or may not work with the existing packages? I put qt3 into /usr/local so I avoid problems
with qt4.
That tells me you don't know anything about qt3 or qt4. There are no
name conflicts with the two libraries. The only issue is the PATH for a
few development executables like qmake and moc. If you are building for
qt3, you set the PATH one way. For qt4, another. It can be easily
scripted.
/usr and
/usr/local are usally configured on most distributions linker
paths and it's in the PATH so then I don't as the packager have to jump
through hoops etc.
Configured for what? /usr/local/{bin,lib} are empty by default. You folks can do what ever you wish but for me I
am sticking to FHS and
puting this thing into /usr/local.
Have you *read* the FHS? What does it say about /opt?
Let me read it for you: "/opt is reserved for the installation of add-on
application software packages. A package to be installed in /opt must
locate its static files in a separate /opt/<package> or /opt/<provider>
directory tree, where <package> is a name that describes the software
package and <provider> is the provider's LANANA registered name."
Did you read the section on /usr/local?
I don't know where all this /opt and company
came from but.....
You are right. You don't know.
When I finally get to rebuilding TDE I will put
the whole thing
into /usr/local. It will not interfere with KDE4 and QT4 and as an added
benifit I don't have to mess with PATH nor the linker path etc. It just
works. ;)
Your system your rules. May I suggest you think about changing /opt or
where ever you
installed this beast and place your work into /usr/local as well.
You may suggest, but it is a poor suggestion. How would you have a
trinity-3.5.13, trinity-3.5.14, and a trinity-dev on the same system?
Do this in /usr/local:
lrwxrwxrwx 1 root root 9 Dec 14 21:55 qt -> qt-3.3.8d
drwxr-xr-x 11 root root 4096 Dec 1 2005 qt-3.3.5
drwxr-xr-x 11 root root 4096 Nov 3 2007 qt-3.3.8
drwxr-xr-x 11 root root 4096 Apr 22 2007 qt-3.3.8-nomysql
drwxr-xr-x 11 root root 4096 Dec 14 21:55 qt-3.3.8d
drwxr-xr-x 12 root root 4096 Mar 5 2008 qt-4.3.4
drwxr-xr-x 13 root root 4096 May 21 2009 qt-4.5.0
drwxr-xr-x 13 root root 4096 Aug 18 2009 qt-4.5.2
drwxr-xr-x 14 root root 4096 Oct 12 2010 qt-4.7.0
drwxr-xr-x 14 root root 4096 Jan 10 15:04 qt-4.8.0
lrwxrwxrwx 1 root root 9 Aug 18 2009 kde -> kde-3.5.10
drwxr-xr-x 7 root root 4096 Dec 12 2006 kde-3.5.2
drwxr-xr-x 7 root root 4096 Aug 18 2009 kde-3.5.10
drwxr-xr-x 7 root root 4096 Dec 19 22:18 trinity -> trinity-3.5.13
drwxr-xr-x 7 root root 4096 Dec 19 12:34 trinity-dev
drwxr-xr-x 5 root root 4096 Dec 18 21:06 trinity-3.5.13
I already do so a few symlinks and it done. I have read up on how this is
done. I just usally use the package manager to this, then I don't have to
mess with it.
In Summary I have a plan, between pacman package manager and a few symlinks I
can do what you suggest and then some. I like flexibility ;)
My distro my rule, my computer my rules.