April 21, 2019

.comment: A Look at KDE2 - page 2

What's New?

  • October 25, 2000
  • By Dennis E. Powell

Upgrading from KDE-1.x is relatively simple if you take a little care; those who don't are likely to hit some snags. Begin by gathering together everything you need, because part of the process involves working in the console, unless your distribution has all the binaries and one of those trick installer applications (which I don't have, don't trust, and don't want, but that's just me). If you're installing from source and are currently using some version of KDE, you'll certainly be in the console. But be ye not afraid, for it's all easy.

First thing to do is get QT-2.2.1, the latest free edition. If there's a binary available for your Linux distribution, good for you. Otherwise, download the source from the Trolls (or, I now discover, KDE's ftp site) and build it.

KDE2 and QT-2.2.1 are available in binaries for many architectures at the KDE ftp site. Yes, get all the packages for your architecture and install them using either RPM or DEB, as the case may be.

For sturdy sorts who like to roll your own, install the new QT before you build KDE2. I'll give my recipe here, though I'm sure there are far more elegant methods.

On my machine, /usr/lib/qt is a symlink that I can point to either /usr/local/lib/qt-1.44 or /usr/local/lib/qt-2.2.1, depending on whether I want to run KDE2 or KDE-1.1.2 (though I'll soon delete both qt-1.44 and kde-1.1.2, this makes upgrading future QT versions easy, with the old one automatically backed up). Likewise, my /opt/kde is a symbolic link that points to whatever version of KDE I care to run. When installing QT-2.2.1, I opened the tarball in /usr/local/lib and renamed its directory to /usr/local/lib/qt-2.2.1, then changed the symlink to make /usr/lib/qt, which is where my system believes QT ought to live. Then I changed to /usr/lib/qt and did this:

CXXFLAGS=' -mpentium" ./configure -sm -gif -system-jpeg -system-libpng

The part before ./configure is optional; it simply optimizes for a Pentium processor. But the rest is essential, enabling session management, GIF support, JPEG support, and PNG support.

The user is then asked to agree with one or the other of the licenses, in response to which "yes" must be typed. Then it's simply a matter of doing "make." The compilation takes a while--more than an hour on a 500 MHz machine with 256 megs of memory. Once it's done, there's nothing more to do--no "make install" or anything of that sort. It builds in place.

The 13 KDE2 tarballs (plus one of the i18n tarballs if you need it; I never have, because I don't need the internationalization--that's what i18n means--they provide) are copied into /usr/local/src. My method is to open them as I build them, so I don't get lost as to what I've built and what I haven't. They're compressed with bzip2; I batch unzip them (bzip2 -d kde*.bz2), which leaves the uncompressed tarballs (tar xvf [filename] to open them).

They must be built and installed in order: kdesupport first, then kdelibs and kdebase. After this, you can build and install the rest in whatever order appeals to you; I do it alphabetically. The build instructions are the same for all:

[compiler flags] ./configure [prefix] [other options]

On my machine this translates to:

CXXFLAGS=' -mpentium' ./configure --prefix=/opt/kde --disable-debug

This means I want Pentium optimization (there being no K6-2 optimization in EGCS-2.91), I want the results to go into /opt/kde (having made a directory named /opt/kde2, and having changed my /opt/kde symlink to point to it), and I don't want to build debug code into the apps (to reduce codesize and speed loading and execution).

Once configure has chugged to completion (a minute or so in most cases), it's "make," which can take from a few minutes in kdesupport to more than an hour for kdelibs, kdebase, and koffice, and then "make install." You need, of course, to be root to do all this. The whole business takes about six hours here, though obviously I don't need to be present for all of it. It's a great time to clean the office, and I plan oneday to spend the time in exactly that way.

If you are upgrading from an existing KDE installation, it is highly recommended to make a backup of the ~/.kde and ~/Mail directories. KDE2's applications will change the configuration files in the home .kde directory, and the new KMail's indexing is different, making backing out if necessary difficult without a backup (betcha can guess: I use symlinks here, too, ~/.kde pointing to ~/kde1config or ~/kde2config, and ~/Mail pointing to ~/Mail1 or ~/Mail2).

Once sure everything's where it should be, and any symlinks are pointed where they should be, type the command that fires the whole business up. Here, it's the good old "startx." And then....

Most Popular LinuxPlanet Stories