The Answer Gang

By Jim Dennis, Karl-Heinz Herrmann, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!

---

Upgrading KDE

From Tom Brown

Answered By: Thomas Adam, Heather Stern

OK, I'm about at my wit's end here (doesn't take much, I know). I'm currently running KDE 3.1, and want to upgrade it. I've yet to figure out how, even using binary RPM's from Suse (my distro). No matter where I start, I'm getting lots and lots of dependency errors. I've looked on the KDE web site for some sort of help or tutorial, but haven't found anything useful.

[Thomas] Welcome to dependency hell. Oh, do I have to guess what these errors are? Please, Tom -- supplying accurate information should be a matter of course for you. You are a member of TAG. Consider it as though you were answering the question. You'd want to see some evidence of what was going on.

First, is there a shell script that will automate the process (assuming I've downloaded the huge pile of individual KDE packages), or is there a way to force Suse's YOU to upgrade from KDE 3.1 to either 3.2 or 3.3? Failing that, is there documentation that takes me step by step through the process without assuming I'm a kernel programmer or something?

[Thomas] Nope. YOU should be able to do it. Indeed, you can probably even use apt-get for SuSE There is always the '--nodeps' option to RPM, but I cannot stress ENOUGH the inherent danger that brings with it. It is not a recommended thing.

The best I've found is instructions on installing KDE packages from source, but nothing I've found tells me in what order the packages go. I've tried starting with the "base" RPM, but that mustn't be it, since I get so many dependency errors.

[Thomas] Well, I had a quick look through some files I have stored locally. I found this in SuSE's RPM source packages for KDE:

#
# KDE 3.2 packages for SuSE distributions
#

Disclaimer:

  These packages have NOT been tested at all and SuSE do NOT recommend to
  upgrade to these. However we build these packages for convenience, but
  it is your risc to use them ;)
    You should not update, if you want to have a stable system and expect
  to get security updates for your installation.

To install these packages via command line you need to
  * rpm -e kdebase3-SuSE kdenetwork3-mail
    (kdebase3-SuSE has not yet been ported to KDE 3.2 and plain rpm
     can not handle the move from kmail to kdepim3 package correct).
  * rpm -Uvh taglib*rpm
  * install flac and gnokii from your CD/DVD
  * rpm -Fvh *.rpm

An alternative way would be to use the yast_source from ftp.suse.com KDE
update packages.

Known issues:
  * Qt 3.3.0 final has not been released yet, we expect it next week
    and it will be avaible on ftp.suse.com.
    The qt packages in these directories contain a late snapshot
    (Qt 3.2 would need many patches, so we decided to go the 3.3 way)
  * Several issues with updating old configurations, these will be
    addressed with SuSE 9.1. However SuSE 9.1 will not fix these, when
    you have already updated to KDE 3.2. So you might backup your
    ~/.kde directory first.
  * kdebindings packages are missing atm, they need further fixes and
    will appear on ftp.suse.com later

[Heather] Woes with upgrading a major desktop beyond the supported scope of your vendor are not limited to one distribution. The lesson here is simple: when taking a package (or in this case a big, big set of packages) beyond the package manager's scope, backup everything you'd need to set things back on the package track, and don't just prepare for glitches but expect to walk through a gantlet of them.

The effort to stray off the beaten path is paid off in getting the nice new features, fixes, and i18n updates far ahead of your neighbors. With care during setup you can also make it easier to update yourself from the project source trees directly with less fuss. The scuffs and scratches will heal, and you'll learn to hang-glide with open source wings...

Midnight commander (mc) with its ability to pop open rpm files and let you look at the post-install scripts, may be invaluable to helping you play safely on the bleeding edge too; look at what merges are made into menu systems and system-config directories. What you learn from that may help you with merging other off-brand packages from their true sources.

---

This page edited and maintained by the Editors of Linux Gazette
HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

---