Editing Dependency hell (section)

== Problems ==
Dependency hell takes several forms:

; Many dependencies
: An application depends on many [[Library (computing)|libraries]], requiring lengthy downloads, large amounts of disk space, and being very portable (all libraries are already ported enabling the application itself to be ported easily). It can also be difficult to locate all the dependencies, which can be fixed by having a repository (see below). This is partly inevitable; an application built on a given [[computing platform]] (such as [[Java (software platform)|Java]]) requires that platform to be installed, but further applications do not require it. This is a particular problem if an application uses a small part of a big library (which can be solved by [[code refactoring]]), or a simple application relies on many libraries.<ref name="jamesdonald">{{Cite web
| last = Donald
| first = James
| title = Improved Portability of Shared Libraries
| archiveurl=https://web.archive.org/web/20070926130800/http://www.princeton.edu/~jdonald/research/shared_libraries/cs518_report.pdf
| archivedate=2007-09-26
| publisher = Princeton University
| date = 2003-01-25
| url = http://www.princeton.edu/~jdonald/research/shared_libraries/cs518_report.pdf
| accessdate = 2010-04-09}}</ref>
; Long chains of dependencies
: If {{code|app}} depends on {{code|liba}}, which depends on {{code|libb}}, ..., which depends on {{code|libz}}. This is distinct from "many dependencies" if the dependencies must be resolved manually, e.g., on attempting to install {{code|app}}, the user is prompted to install {{code|liba}} first and on attempting to install {{code|liba}}, the user is then prompted to install {{code|libb}}, and so on. Sometimes, however, during this long chain of dependencies, conflicts arise where two different versions of the same package are required<ref name="Dependency-Carousel">{{cite journal
| title = It's Good Work When You Can Find It; The Dependency Carousel
| last = Stevens
| first = Al
| journal = J-DDJ
| volume = 26
| issue = 5
| pages = 121–124
| issn = 1044-789X
| url = http://www.drdobbs.com/blog/archives/2008/12/its_good_work_w.html
| archiveurl=https://web.archive.org/web/20110811080730/http://drdobbs.com/blogs/architecture-and-design/228700267
| archivedate=2011-08-11
| publisher = www.drdobbs.com/blog
| date = 2001-05-01
| accessdate = 2010-04-10}}</ref> (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.
; Conflicting dependencies
: Solving the dependencies for one software may break the compatibility of another in a similar fashion to [[whack-a-mole]]. If {{code|app1}} depends on {{code|libfoo 1.2}}, and {{code|app2}} depends on {{code|libfoo 2.0}}, and different versions of {{code|libfoo}} cannot be simultaneously installed, then {{code|app1}} and {{code|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 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 of those packages.
; [[Circular dependencies]]
: If {{code|application A}} depends upon and can't run without a specific version of {{code|application B}}, but {{code|application B}}, in turn, depends upon and can't run without a specific version of {{code|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.
; Package manager dependencies
: It is possible<ref name="linuxdependencyhell"/> for dependency hell to result from installing a prepared package via a package manager (e.g. [[APT (Debian)|APT]]), but this is unlikely since major package managers have matured and official repositories are well maintained. This is the case with current releases of [[Debian]] and major derivatives such as [[Ubuntu (operating system)|Ubuntu]]. Dependency hell, however, can result from installing a package directly via a package installer (e.g. [[RPM Package Manager|RPM]] or [[dpkg]]).
;Diamond dependency
:When a library A depends on libraries B and C, both B and C depend on library D, but B requires version D.1 and C requires version D.2. The build fails because only one version of D can exist in the final executable. 
: Package managers like [[yum (software)|yum]]<ref>{{Cite web |url=http://www.techbrown.com/fix-centos-rhel-fedora-yum-dependencies-hell-problem.shtml |title=Yum Dependency Hell |access-date=2015-12-28 |archive-url=https://web.archive.org/web/20161219072303/http://www.techbrown.com/fix-centos-rhel-fedora-yum-dependencies-hell-problem.shtml |archive-date=2016-12-19 |url-status=dead }}</ref> are prone to have conflicts between packages of their repositories, causing dependency hell in Linux distributions such as [[CentOS]] and [[Red Hat Enterprise Linux]].