.comment: Putting KDE in Its Place
By: Dennis E. Powell
Wednesday, July 26, 2000 08:15:51 AM EST
URL: http://www.linuxplanet.com/linuxplanet/opinions/2112/1/
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.
The FHS--Often Cited, Seldom Read
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/<package> directory tree, where <package> is a name that describes the software package.
Programs to be invoked by users shall be located in the directory /opt/<package>/bin. If the package includes UNIX manual pages, they shall be located in /opt/<package>/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.
Vast Avoidance of Common Sense
Without exception, the people who have argued to
me (and at me) in favor of KDE being placed in /usr are people who
use RPMs or other binary package management systems to install software. Now,
by definition these users don't have any practical reason for caring
where KDE goes, as long as once it's there it runs. Some of this no
doubt comes from the "mine is bigger than yours" aspects of loyalty
to a distribution, which is already threatening to fork Linux so thoroughly
that soon it will more resemble a paintbrush than a fork. But that scarcely
lets Red Hat and its distributional followers off the hook. Perhaps they have
good business reasons for making users obligated to use their RPMs; if so, good
for them. But not good for Linux.
There are two groups of users, those who don't
care where KDE and similar packages get installed and those who do. Those who
do have compelling reason for it to be put into /opt, a
possibility not inconsistent with the FHS. Distributions that put it in
/usr do so for reasons other than concern for users. A lot of
people still build their own software packages (and Heaven help us when they
stop), and many of these build things like KDE fairly regularly, using interim
code during development cycles. I'm trying to think when, since the release of
KDE-1.0, I've installed a straight release version of KDE, and except for two
occasions when I upgraded Linux distributions and therefore had release
versions for a few minutes, I can't. I'm not alone. And if KDE had been in
/usr, my life would have been devoted to dealing with some truly
fierce computer problems involving KDE (instead of, say, trying to make the GL
parts of Xscreensavers work at a reasonable refresh rate under XFree86-4.01, a
continuing bugaboo).
Distributors could point their RPMs at
/opt/kde and maintain the fealty of many users to their RPMs if
that is their desire, while letting the test drivers and roll-your-owners have
their day. We could all live together in the bright sunlit meadows of peace and
happiness. At a minimum, they could make their RPMs redirectable and say so,
perhaps even providing instructions. It's not difficult, but the effort to keep
users from knowing anything about the command prompt is such that a goodly
number of users now couldn't install an RPM from a # to save their lives, so
instructions would be necessary. The real answer is to put KDE into
/opt.
Yes, yes, the argument is made that people are
upgrading software all the time, compiling it themselves, the destination of
which is /usr. And there's a distinction to be made, too: when I
seek to upgrade, say, Xscreensavers, I get the source tarball, and either it
builds or it doesn't. If it doesn't, and if I can't figure out why and fix it, I
can blow off the whole project and live a few days more with the version I
have. But KDE is different. It comes in 13 separate packages, and as
development progresses today's compilations are not necessarily compatible with
yesterday's. So perhaps the first few packages, including the KDE libraries,
compile nicely, but then I get to a crucial package that is total devastation.
But I've done "make install" on the previous packages. Now I'm stuck
with a crippled KDE--unless I'm installing to /opt/kde, in which
case I've kept a backup of the previous version and can fall back on it until
things are sorted out. (Nor is this hypothetical. During a period of about 10
days this month, the version of QT against which KDE2 was to be compiled was in
a constant disarray, as sometimes happens during development, and I was
cranking out a half-baked KDE2 daily. I simply deleted it and went on with my
life, hoping the next day's code would compile for me. Finally, it did, but it
would have been an unhappy time indeed if I'd done "make install" to
/usr.)
Additionally, there ought to be more than one way
of doing a thing, and with KDE in /opt instead of
/usr, there is. One can install, backup, and delete, upgrade,
downgrade, do whatever one wants far more readily when it's in
/opt, by use of a package manager if that's the user's choice, or
by use of a simple file manager or command prompt. Linux is and ought to remain
a home for tinkerers. If you want to edit some of the possible configurations
for, say, Konsole, it's a lot easier to go to
/opt/kde/share/apps/konsole than it is to go poking around in
/usr/share. All that putting KDE in /usr does is make
the user more reliant on the distributor, and that is a Bad Thing.
The fact is that common sense dictates that KDE
(and similar packages) go into /opt/<packagename>
instead of /usr; that anyone, never mind a number of
people, thinks otherwise is a true mystery.
Have It Your Way
Okay. The distributors have made their decision and you have made yours, and they're incompatible. Are you helpless? By no means. Here's how you can put your KDE where you want it, instead of where someone else, for reasons known only to them, wants it.
Go to
ftp://ftp.kde.org/pub/kde/stable/1.1.2/distribution/rpm/COL-2.3/i386/.
This is the directory of KDE-1.1.2 packages for Caldera OpenLinux, which go
into /opt. Download them.
All you need to do is uninstall your existing KDE
RPMs, install the ones from the KDE website, and change your KDE environment,
which in Red Hat is in /etc/profile.d/kde.sh. (It's a good idea to
take a look at this file before you upgrade, just to make sure it is as
advertised.)
Start KDE and life will be as it should be, and you will have control of which version or versions you have, now and forever.