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:

* One of the needed libraries cannot be found, or your crusty vendor-provided package calls for a version of a library that is extinct in the wild.
* A dependency conflict occurs.  While Linux has no trouble having multiple versions of the same shared library installed at the same time, it doesn't at all like applications which try to ''link'' to two different versions of the same library from within the same process.  There are other reasons, of course, why two libraries may not coexist in the same process--often relating to one or both engaging in gratuitous NamespacePollution, FilesystemPollution, or EnvironmentPollution (these aren't the fault of RPM, necessarily, but it often manifests itself when the user does an install).
* The dependency list for some package is incorrect, and rather than getting a "missing library" message from the installer, you get the dreaded "missing file" error instead.  Good luck trying to figure out what package out there in cyberspace contains that missing file.  (You can, of course, ask the maintainer of the package that wants it, but you might be told to RtFm).