RPM hell: a real-life scenario

You know, I'm trying to update to Fedora Core 6 development. It's all good, except for one itty bitty thing: I cannot upgrade the GNOME desktop to the latest version without losing major applications that I have installed.

Don't miss part two, in which I pick some reader comments apart in a grossly inappropriate and insulting fashion!

For example, trying to update the gnome-panel package with the Smart package manager causes Smart to prompt me to remove, among other essential packages, the Ekiga softphone (and it's not Smart's fault, Smart is just pinpointing me to an issue that cannot be solved by manual RPM usage either).

Among othe things that Smart says, it says it needs to remove Ekiga because evolution-data-server will be upgraded as part of the gnome-panel installation.

Delving a bit into what's really going on:

[rudd-o@andrea] [19:05:54]
[~] > rpm -q ekiga  --requires
/bin/sh
/bin/sh
/bin/sh
GConf2 >= 1.2.1
evolution-data-server
libICE.so.6
libORBit-2.so.0
libSDL-1.2.so.0
libSM.so.6
libX11.so.6
libart_lgpl_2.so.2
libatk-1.0.so.0
libaudiofile.so.0
libbonobo-2.so.0
libbonobo-activation.so.4
libbonoboui-2.so.0
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libcairo.so.2
libdl.so.2
libebook-1.2.so.5
libedataserver-1.2.so.7
libesd.so.0
libgcc_s.so.1
libgcc_s.so.1(GCC_3.0)
libgconf-2.so.4
libgdk-x11-2.0.so.0
libgdk_pixbuf-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgnome >= 2.0
libgnome-2.so.0
libgnome-keyring.so.0
libgnomecanvas-2.so.0
libgnomeui >= 2.0
libgnomeui-2.so.0
libgnomevfs-2.so.0
libgobject-2.0.so.0
libgthread-2.0.so.0
libgtk-x11-2.0.so.0
libm.so.6
libm.so.6(GLIBC_2.0)
libopal_linux_x86_r.so.2.2
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpopt.so.0
libpt_linux_x86_r.so.1.10.0
libpthread.so.0
libstdc++.so.6
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4)
libxml2.so.2
libz.so.1
opal >= 2.2.1
pwlib >= 1.10.0
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
scrollkeeper

Let's see. Ekiga requires evolution-data-server -- any version will suffice... but what's a little lower on the list? Oh, we find libedataserver-1.2.so.7 -- one of the automatically detected file dependencies!

Of course, since my current evolution-data-server package provides that file, but the new evolution-data-server provides a new file (and, in addition, evolution-data-server isn't parallel-installable), I'm fucked. Never mind that the new version of libedataserver is binary compatible with the old version and thus Ekiga should just run fine with it.

This is bullshit, man. Together with renaming major libraries' package names, this dependency autodetection that causes hard-coded file names (with no respect or consideration whatsoever as to binary-compatible upgrades) is the most gross misuse of the RPM package manager's abilities. Bullshit! No wonder we're all knee-deep in this RPM bullshit-hell.

What? I hear you saying I should wait until someone rolls an Ekiga package that requires the new libedataserver? Bullshit! My old Ekiga is perfectly and binarily compatible with the new evolution-data-server.

Do I hear "wait until FC6 is out"? Bullshit again! Why couldn't I install packages from FC4 or FC3 on my FC5 install? Again, lazy packaging and a broken dependency autodetector.

Let me be perfectly clear: this is a shortcoming not of the package format but of the shortsightedness of the packagers. Sure, it's easy as hell to let RPM determine dependencies using this brain-dead method. Of course, solutions (not for the lazy) abound:

• actually put the dependencies manually, referring to the file if needed (without minor version specifics), or to the version of the package that provides it.
• (pays in the long term) making the dependency detector require a major version of a library, and (possibly) require a minor version at or above the version number of the version of the library at the time the package was compiled
• package RPMs with foresight as to multiple versions installed.

What's not acceptable:

• making me keep old versions of software, just because I want to run legacy applications
• making me impossible to upgrade my system, because I have some packages which could run perfectly fine with new library minor versions (or analogues) -- but block the upgrades because of the braindead packages' requirements
• making me recompile from source RPMs to use my favorite applications, when it's perfectly possible to run legacy and unmaintained apps without manual intervention from the users' part

This issue will not be cured (or helped) by:

• Fedora Unity
• A centralized package name and dependency registry (although it would help other types of RPM hell problems)
• A different package format (RPM is good enough)

I swear to god, if this goes on by the time FC6 is out, I'm changing to Ubuntu. Sure, the DEB package format doesn't have parallel package installation ability, but at least they place much greater efforts in consistent packaging, and what the hell, packagers aren't putting any effort into making parallel packages installable anyway (apart from renaming the package name to libXYZ2, which is also stupid because it makes sane upgrades difficult and overloads the package name with a different purpose).

Digg users: please digg this story so more RPM packagers around the world find out and get their act together!