.comment: Putting KDE in Its Place

Why File Locations Matter

Here we are, a few weeks away from the release of a new version of KDE, and once again there's a virtual Trevi Fountain of urination tournaments over where in the Linux file system KDE belongs.

Unlike a lot of the just-for-the-sake-of-arguing disputes that take place in the Linux world, this one actually matters to a lot of people for real, demonstrable reasons. It is also one place where a single distribution has dictated a standard--out of sheer, brute force, not because that standard is the best answer.

For the first year or so of its existence, KDE was typically placed in /opt/kde (though some users put it in /usr/local/kde). This made sense for a number of reasons, chief among them that if one wanted to build an incremental upgrade from source, backing up the old, working version was a simple thing, as was restoring it if the compilation didn't go as planned, but waited until, say, kdebase before blowing up. Everyone was happy with the arrangement.

In due course, Red Hat included KDE in its Linux distribution, alongside Gnome, which was developed largely under the aegis of Red Hat. The inclusion of KDE is to Red Hat's credit; the placement of it is not. Red Hat put KDE in /usr, where its binaries are intermingled with all the others in /usr/bin, its libraries with the /usr/lib contributions of other system programs, and so on. Now, if you got halfway through the compile of an upgrade aimed at /usr, you were victim of a threaded conical device. In effect, this meant that you were limited to RPM packages produced by, or at least for, Red Hat distributions. There were many programs developed for KDE-1.x that were not included in the KDE distribution and that were often placed in /opt/kde/bin; with this system they would go into /usr/bin when a user compiled them or (rarely) found an RPM. If a new KDE version's libraries were different from those against which the program had been compiled, one could end up with a /usr spattered with dead files.

Mandrake and other Red Hat derivative distributions followed Red Hat's example. This led to a considerable forking, especially among binary RPMs.

A week or so ago, the new KDE2 beta RPMs for Mandrake Linux no longer would run alongside a KDE-1.x installation in /usr. Now they overwrite KDE-1.x. Whether the KDE developers, who usually like to decide themselves when a new version is ready, are happy with this is unknown. But as of now, one very popular Linux distribution has RPMs that make the pre-release KDE2 the only KDE on the system, without any very easy way to backup the original. (Yeah, there are the original distribution RPMs--I've heard it all before; but there's not much way using Mandrake RPMs to keep both a working production installation of KDE-1.1.2 and a testdrive version of KDE2 on the same machine. Besides, there are individual programs within KDE, notably KMail, that have been upgraded outside of the distributional RPM system.)

Understand: I think KDE2 is just great. I use it exclusively, as I have since last November. But I'm also willing to accept little shortcomings in developmental software that many users would find objectionable and that I suspect the KDE developers would not wish to have speak for the quality of their work. Example: I compiled new source code a couple of days ago from the KDE CVS tree (a system, in case you don't know, whereby you can get code that is just hours, in some cases minutes, old). In the two weeks since last I built KDE there had been much progress, but as is inevitable during development new problems had appeared. I discovered this when I tried to save an email address to the KMail addressbook and instead of saving the address erased the entire addressbook. I expect this kind of thing. Many users, especially those who only install that which they can get on binary RPM, might not.

And that is why putting KDE into /usr is just plain inconsiderate and unwise. Let me explain further.