IBM's ThinkPad-Linux support project being dropped

dep dep
Mon May 17 11:33:40 PDT 2004


begin  Matthew Carpenter's  quote:
| Perhaps I need a little educating.  What is the reason that putting
| KDE in /opt makes life any easier?  

for this we must consult the fhs. it specifies that when kde is put 
into /usr or /usr/local, then the files must be spread out over that 
directory. when they are in /opt, they must be kept together. thus, 
when kde is in /opt, its executables are in /opt/kde/bin, its shared 
files in /opt/kde/share, and so on. when it is in /usr, its 
executables go into /usr/bin, its shared files into /usr/share, and 
so on -- and it shares those directories with lots of other files 
from lots of other applications.

now. let's say you want to try a new version. if you want to try a new 
version of most anything else, you download the source code, you 
build it, and if the build goes well -- which is to say completes 
without erroring out -- you do "make install" and it installs, 
typically in /usr/local (again, spread all over the place, in 
/usr/local/bin, etc.) and that's that. (of course, you want to 
uninstall any previous version you had, or install the new version 
over it, so you don't have two competing versions on your machine.) 
the crucial thing here is that the application is in a single 
package, so it either builds or doesn't.

with kde, or gnome, or anything else that comes in lots of smaller 
packages, /opt is important because you can easily back up /opt/kde, 
but you cannot easily back up any kde components in, say, /usr. why 
does this matter?

let's say you get and build kdelibs, the first package of the dozen or 
so in kde. it builds just fine. you do "make install" and now you 
have installed *part* of kde -- enough to break the old version, but 
not enough to run on its own. now you build kdebase, the second 
package in the build order, and it blows up. for some reason -- a 
bug, whatever -- the build fails. now you have a broken kde (or 
gnome, if you had *it* in /usr or /usr/local). if your kde was in 
/opt, no big deal -- just restore your backup and you're running the 
previous version and all is well. (on my machines, kde is /opt/kde, 
which is a symlink to the actual kde being used, which might be 
/opt/kde3-051902, for the date it was built. were i to build from 
source today, i'd delete that symlink, make a directory called 
/opt/kde3-062102, and symlink to that. then, when running 
./configure, i would specify, as i have since 1998, prefix=/opt/kde. 
and if things blew up, i could delete the /opt/kde symlink, make a 
new one pointing to /opt/kde-051902, and be back running kde within a 
minute, making it easier, then, to sort it all out. nothing even 
remotely close to this is possible with kde splattered all over /usr 
or /usr/local.
-- 
dep

http://www.linuxandmain.com -- outside the box, barely within the 
envelope, and no animated paperclip anywhere.



More information about the Linux-users mailing list