.comment: A Look at KDE2
Getting It

Dennis E. Powell
Wednesday, October 25, 2000 04:38:13 AM
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....
Next: KDE2 In All Its Glory »