From Wikipedia, the free encyclopedia

Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages.

Often, rather than 'reinventing the wheel', software is designed to leverage other software components that are already available, or have already been designed and implemented for use elsewhere. This could be compared to how people building a house might buy off-the-shelf components, such as bricks, windows, and doors, rather than building everything themselves. Even for a builder, it can be a problem if a building is designed for a certain door type, and only doors with different specifications are available. However, in the software world, where components evolve rapidly, and components are often dependent on other components, this problem is more pronounced.

On some specific computing platforms, "dependency hell" may go by another name, reflecting the specific packages or software that has a dependency conflict. For example, on Windows, the term DLL hell is used, reflecting the fact that most problems occur when a program tries to access an underlying DLL software component.

The issue of dependency hell may be regarded as an anti-pattern, where the fault lies less with the suppliers of the products than with the framework into which they have to fit.

The most obvious (and very common) solution to this problem is to have a standardised numbering system, wherein software uses a specific number for each version (aka major version), and also a subnumber for each revision (aka minor version), e.g.: 10.1, or 5.7. The major version only changes when programs that used that version will no longer be compatible. The minor version might change with even a simple revision that does not prevent other software from working with it. In cases like this, software packages can then simply request a component that has a particular major version, and any minor version. As such, they will continue to work, and dependencies will be resolved successfully, even if the minor version changes.

Some package managers can perform smart upgrades, in which interdependent software components are upgraded at the same time, thereby resolving the major number incompatibility issue too.

Many current Linux distributions have also implemented repository-based package management systems to try to solve the dependency problem. These systems are a layer on top of the RPM, dpkg, or other packaging systems that are designed to automatically resolve dependencies by searching in predefined software repositories. Typically these software repositories are FTP sites or websites, directories on the local computer or shared across a network or, much less commonly, directories on removable media such as CDs or DVDs. This eliminates dependency hell for software packaged in those repositories, which are typically maintained by the Linux distribution provider and mirrored worldwide. Although these repositories are often huge it is not possible to have every piece of software in them, so dependency hell can still occur. In all cases, dependency hell is still faced by the repository maintainers. Examples of these systems include Apt, Yum, Urpmi, emerge and others.

Because different pieces of software have different dependencies, it is possible to get into a vicious circle of dependency requirements, or (possibly worse) an ever-expanding tree of requirements, as each new package demands several more be installed. Systems such as Debian's APT can resolve this by presenting the user with a range of solutions, and allowing the user to accept or reject the solutions they prefer or dislike, respectively.

• APT - Debian package management system
  • Aptitude - Frontend for APT which includes an interactive dependency conflict resolver
• RPM Package Manager - package management system for Redhat, Suse, Mandriva distributions
• Pacman
• Portage - Gentoo package management system
• Pkgsrc - Originally from NetBSD, now works with a variety of OS's.
• Urpmi
• Yum

• Coupling - Forms of dependency among software artifacts
• Configuration management - Techniques and tools for managing software versions
• DLL hell - A form of dependency hell occurring on Microsoft Windows
• Extension conflict - A form of dependency hell occurring on older versions of Mac OS
• JAR hell - A form of dependency hell occurring in the Java runtime system