Dependency hell
|
|
Dependency hell occurs in package-based operating systems - particularly Linux - and is a colloquial term for the frustration of many users who have installed software packages which have dependencies on specific versions of other packages. This version information is often part of the package management system, which can refuse to install software without the precise versions of its prerequisite packages installed.
Even if the version is newer than the one being requested by the installing software, it may present conflicts, and package managers like APT and RPM will refuse to install, although RPM's refusal can be subverted with the --nodeps switch (the use of which can also further convolute the package dependency tree, but sometimes helps).
Many current Linux distributions have implemented repository-based package management systems to try to solve the dependency problem. These systems are a layer on top of the RPM or DEB packaging systems that is designed to automatically resolve dependencies by searching in predefined software repositories. Typically these software repositories are http or ftp sites, directories on the local computer or shared across a network or 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. Although these repositories are often huge it is not possible to have every piece of software in them, so dependency hell can still occur. It is also still faced by the repository maintainers. Examples of these systems include Apt, Yum, Urpmi and others.
Because different pieces of software have different dependencies (the most common being different compiler versions), this often leads to a conflict between the software that is required and the software that is installed. 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.
Though the concept of dependency hell has been very common since the rise of package managers like APT and RPM, it's actually about as old as UNIX itself. Most software that is distributed via tarballs of the source code contain a configure script, which takes inventory of what the user's system will allow the compiler to do, and sometimes also checks for other software installed on the system that it might require for operation. Like RPM's dependency-borne snowball effect, this can also lead to hunting down and installing various versions of extra software, just so the configure script of the first tarball to be installed will be satisfied (since it will produce an error and quit if it does not find something it needs). With the rise of package-based operating systems, this form of dependency hell is becoming less common, but will likely be around for quite a while, depending on how much longer current operating systems that do not use package management software can go without the convenience and relative speed of such software.
Despite that convenience, not all software developers will distribute their software via RPM and its ilk, which ensures that tarball-based software will live on indefinitely. A possible solution could be Autopackage — a program that automatically checks all dependencies and downloads them.
There are recent solutions eliminating the reason for dependency hell. Konvalo since around 2001 deploys global filesystems to run software directly without installation "on a given host". That concept eliminates the missing-or-conflicting dependencies problems as well as the need for package managers solving it. Given the availability of global filesystems like Coda the era of packaged-based OS may come to its end.