On Thursday 19 January 2012 05:55:21 pm Bruce Dubbs wrote: > Baho Utot wrote: > > 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 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 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. > 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. > > /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. 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. > > > 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? Yes I have read that. In fact I have a pdf document. > > 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. Yes as it should be > > > 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? 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. > > 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.