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