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. [1]
The dependency issue arises when several packages have dependencies on the same shared packages or libraries, but they depend on different and incompatible versions of the shared packages. If the shared package or library can only be installed in a single version, the user may need to address the problem by obtaining newer or older versions of the dependent packages. This, in turn, may break other dependencies and push the problem to another set of packages.
Dependency hell takes several forms:
app
depends on liba
, which depends on libb
, ..., which depends on libz
. This is distinct from "many dependencies" if the dependencies must be resolved manually, e.g., on attempting to install app
, the user is prompted to install liba
first and on attempting to install liba
, the user is then prompted to install libb
, and so on. Sometimes, however, during this long chain of dependencies, conflicts arise where two different versions of the same package are required
[3] (see conflicting dependencies below). These long chains of dependencies can be solved by having a package manager that resolves all dependencies automatically. Other than being a hassle (to resolve all the dependencies manually), manual resolution can mask dependency cycles or conflicts.app1
depends on libfoo 1.2
, and app2
depends on libfoo 1.3
, and different versions of libfoo
cannot be simultaneously installed, then app1
and app2
cannot simultaneously be used (or installed, if the installer checks dependencies). When possible, this is solved by allowing simultaneous installations of the different dependencies. Alternatively, the existing dependency, along with all software that depends on it, must be uninstalled in order to install the new dependency. A problem on Linux systems with installing packages from a different distributor (which is not recommended)[
citation needed] is that the resulting long chain of dependencies may lead to a conflicting version of the
C standard library (e.g. the
GNU C Library), on which thousands of packages depend. If this happens, the user will be prompted to uninstall all those packages.application A
depends upon and can't run without a specific version of application B
, but application B
, in turn, depends upon and can't run without a specific version of application A
, then upgrading any application will break another. This scheme can be deeper in branching. Its impact can be quite heavy if it affects core systems or update software itself: a package manager (A), which requires specific run-time library (B) to function, may break itself (A) in the middle of the process when upgrading this library (B) to next version. Due to incorrect library (B) version, the package manager (A) is now broken, thus no rollback or downgrade of library (B) is possible. The usual solution is to download and deploy both applications, sometimes from within a temporary environment.On specific computing platforms, "dependency hell" often goes by a local specific name, generally the name of components.
All popular package managers, including APT, RPM and the FreeBSD Ports Collection, suffer from the problem of destructive upgrades. When you perform an upgrade -- whether for a single application or your entire operating system -- the package manager will overwrite the files that are currently on your system with newer versions. As long as packages are always perfectly backward-compatible, this is not a problem, but in the real world, packages are anything but perfectly backward-compatible. Suppose you upgrade Firefox, and your package manager decides that you need a newer version of GTK as well. If the new GTK is not quite backward-compatible, then other applications on your system might suddenly break. In the Windows world a similar problem is known as the DLL hell, but dependency hell is just as much a problem in the Unix world, if not a bigger one, because Unix programs tend to have many external dependencies.
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. [1]
The dependency issue arises when several packages have dependencies on the same shared packages or libraries, but they depend on different and incompatible versions of the shared packages. If the shared package or library can only be installed in a single version, the user may need to address the problem by obtaining newer or older versions of the dependent packages. This, in turn, may break other dependencies and push the problem to another set of packages.
Dependency hell takes several forms:
app
depends on liba
, which depends on libb
, ..., which depends on libz
. This is distinct from "many dependencies" if the dependencies must be resolved manually, e.g., on attempting to install app
, the user is prompted to install liba
first and on attempting to install liba
, the user is then prompted to install libb
, and so on. Sometimes, however, during this long chain of dependencies, conflicts arise where two different versions of the same package are required
[3] (see conflicting dependencies below). These long chains of dependencies can be solved by having a package manager that resolves all dependencies automatically. Other than being a hassle (to resolve all the dependencies manually), manual resolution can mask dependency cycles or conflicts.app1
depends on libfoo 1.2
, and app2
depends on libfoo 1.3
, and different versions of libfoo
cannot be simultaneously installed, then app1
and app2
cannot simultaneously be used (or installed, if the installer checks dependencies). When possible, this is solved by allowing simultaneous installations of the different dependencies. Alternatively, the existing dependency, along with all software that depends on it, must be uninstalled in order to install the new dependency. A problem on Linux systems with installing packages from a different distributor (which is not recommended)[
citation needed] is that the resulting long chain of dependencies may lead to a conflicting version of the
C standard library (e.g. the
GNU C Library), on which thousands of packages depend. If this happens, the user will be prompted to uninstall all those packages.application A
depends upon and can't run without a specific version of application B
, but application B
, in turn, depends upon and can't run without a specific version of application A
, then upgrading any application will break another. This scheme can be deeper in branching. Its impact can be quite heavy if it affects core systems or update software itself: a package manager (A), which requires specific run-time library (B) to function, may break itself (A) in the middle of the process when upgrading this library (B) to next version. Due to incorrect library (B) version, the package manager (A) is now broken, thus no rollback or downgrade of library (B) is possible. The usual solution is to download and deploy both applications, sometimes from within a temporary environment.On specific computing platforms, "dependency hell" often goes by a local specific name, generally the name of components.
All popular package managers, including APT, RPM and the FreeBSD Ports Collection, suffer from the problem of destructive upgrades. When you perform an upgrade -- whether for a single application or your entire operating system -- the package manager will overwrite the files that are currently on your system with newer versions. As long as packages are always perfectly backward-compatible, this is not a problem, but in the real world, packages are anything but perfectly backward-compatible. Suppose you upgrade Firefox, and your package manager decides that you need a newer version of GTK as well. If the new GTK is not quite backward-compatible, then other applications on your system might suddenly break. In the Windows world a similar problem is known as the DLL hell, but dependency hell is just as much a problem in the Unix world, if not a bigger one, because Unix programs tend to have many external dependencies.