IBM's ThinkPad-Linux support project being dropped

[Matthew Carpenter]

EEEEEWWWWWWW! 

Thank you for that education, Dennis.  I did not realize those
requirements.  YUCK!
Having most experience with COL, which puts it in /opt, I have seldom had
the chance to experience the difference.  But there is definitely
something much more clean and flexible about the /opt method, now that I
understand the differences.

Logically speaking, sticking kde in /usr COULD be just as clean, since it
could still be implemented as if it were in /opt.  However, that would not
be in accordance with the FHS standards.

Thanks,
Matt

On Fri, 21 Jun 2002 15:17:33 -0400
"dep" <dep at linuxandmain.com> wrote:

> 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.
> _______________________________________________
> Linux-users mailing list -
> http://linux-sxs.org/mailman/listinfo/linux-users
> Subscribe/Unsubscribe info, Archives,and Digests are located at the
> above URL.