Rpm Hell

The RedHatLinux world's answer to DllHell, and yet another example of DependencyHell. RPM, in this case, is RedHatPackageManager, the de-facto (outside the Debian camp, at least) tool used for deploying applications to end-users and handling the dependencies. Not just Red Hat; numerous other Linux distros--SuSE in particular--use rpm.

In Windows-land, the usual strategy is to use InstallShield (or similar tool); include every library that you'll ever need in the distribution, and let InstallShield handle the dependencies. Occasionally, doing this will update an already-installed library and break some other application (one symptom of DllHell).

In the Linux world until recently, folks generally downloaded source distributions, manually collected dependent libraries, and built it by hand. Now that Linux is showing up more and more on the desktops of users who aren't computer experts (and even those of us who are are lazy), various tools which perform a similar function now exist.

Except that in the Linux world, the convention is to distribute an RPM file which lists the dependencies, but doesn't include them; it's up to the installer tool (or the user) to go get them. And often when that occurs--assuming the user can find the bloody thing (there are tools for this as well), that library will have its own dependencies; and the user must hunt down the transitive closure.

This is no longer the common case. Now virtually every popular distribution has a packaging system which automatically resolves and installs dependencies. However, if you need to install a software package which your distribution does not include either the dependencies or references thereto, or your download cache is out of date, or you use one or more mirror sites that are out of date or in process of being updated, you may end up taking a detour back into RpmHell.

There are many ways in which something can go wrong:

View edit of December 7, 2009 or FindPage with title or text search