November 25, 2014
 
 
RSSRSS feed

.comment: Putting KDE in Its Place - page 3

Why File Locations Matter

  • July 26, 2000
  • By Dennis E. Powell

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.

Sitemap | Contact Us