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