.comment: Putting KDE in Its Place - page 2

Why File Locations Matter

Supporters of placement of KDE and similar packages in /usr say that this is mandated by a document called the FHS, for Filesystem Hierarchy Standard. This noble and necessary piece of work seeks to codify the placement of things within the Linux file system. About /opt it says, in part:

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt shall locate its static files in a separate /opt/ directory tree, where

is a name that describes the software package.

Programs to be invoked by users shall be located in the directory /opt//bin. If the package includes UNIX manual pages, they shall be located in /opt//man and the same substructure as /usr/share/man shall be used. . . . .

. . . Distributions may install software in /opt, but should not modify or delete software installed by the local system administrator without the assent of the local system administrator.

About /usr, it says, in part:

No large software packages should use a direct subdirectory under the /usr hierarchy. An exception is made for the X Window System because of considerable precedent and widely-accepted practice. This section of the standard specifies the location for most such packages.

Those who argue for placement of KDE in /usr invariably latch onto the phrase "add-on" and refuse to let go. This rapidly becomes laughable: I've seen arguments that placement depends on whether one compiles the software himself or herself, whether one got the software from the Linux distributor or from the program's author, and even whether it came on the first or second CD of the distribution. (Of course, publishers of RPM-based distributions put the packages where they damn well please, irrespective of the piece of circular plastic whence it originates.)

But there is a more obvious and--heavens!--sensible distinction to be made: the FHS tells us that packages in /opt have to stay together, while those in /usr are splattered all over the place. This means that KDE placed in /opt must be in /opt/kde (or, say, /opt/kde2), while if it's placed in /usr it must be distributed throughout /usr.

Now. Let's suppose that the Reddrake/Man Hat "standard" were to put KDE into /opt. And let's further suppose that Mandrake decided, as they have, to overwrite the existing KDE-1.1.2 with the pre-release KDE2. Let's further suppose a user who is not eager to blow away a perfectly functional system, perhaps augmented by applications not yet ported to KDE2, but who is eager to take a look at KDE2 and who does not care to compile it. What would this user do? Easy: Look in /opt to see what the KDE directory is called. In console mode, rename that directory and make a symbolic link of the original directory name, now pointing to the renamed directory. When time came to install the new KDE2 RPMs, erase the symlink. KDE2 would then be installed into a directory of the name that the KDE-1.1.2 directory once had. Again the user would rename the directory. Then, by creating a new symbolic link, the user could go to KDE2. To go back to KDE-1.1.2, all that would be needed would be is a new symbolic link that pointed to that directory instead. (The same would need to be done for QT and for the user's home .kde directory, in that KDE2 configuration files are incompatible with those from KDE-1.x and from earlier KDE2.) There is no way to do this if KDE is in /usr, so Mandrake has decided that a test drive of KDE2 is a one-way street.