Misplaced Pages

Dependency hell: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 06:44, 21 November 2008 editLirazSiri (talk | contribs)595 edits added software appliances as a solution← Previous edit Latest revision as of 15:27, 14 January 2025 edit undo92.84.240.74 (talk) I think the major number should be different, because semantic versioning says that increasing the minor number should guarantee backwards compatibility (so in this case just installing version 1.3 would allow the app to run) 
(305 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{Unreferenced|date=February 2008}} {{refimprove|date=August 2024}}
'''Dependency hell''' is a colloquial term for the frustration of some software users who have installed ] which have ] on specific ]s of other software packages.


{{Short description|Colloquial term for software requiring many conflicting dependencies}}'''Dependency hell''' is a ] for the frustration of some software users who have installed ] which have ] on specific ]s of other software packages.<ref name="Dependency Hell">{{cite book
== Overview ==
| title = Linux annoyances for geeks
Often, rather than "]", software is designed to take advantage of other ]s 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 ] components, such as bricks, windows, and doors, rather than building ''everything'' themselves.
| author = Michael Jang
| url = https://archive.org/details/linuxannoyancesf0000jang
| url-access = registration
| page =
| publisher = O'Reilly Media
| isbn = 9780596552244
| year = 2006
| accessdate = 2012-02-16}}</ref>


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.
Even for a builder, it can be a problem if a building is designed for a certain door type, and only doors with different ] are available. However, in the software world, where components evolve rapidly, and components are often dependent on other components, this problem is more pronounced.

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

===Platform-specific===
On specific ]s, "dependency hell" often goes by a local specific name, generally the name of components.

* ] - A form of dependency hell occurring on ]
* ] - A form of dependency hell occurring on older versions of ]
* ] - A form of dependency hell occurring in the ]


== Problems == == Problems ==
Dependency hell takes several forms: Dependency hell takes several forms:


; many dependencies ; Many dependencies
: An application depends on many libraries, requiring lengthy downloads, large amounts of disk space, and not being very portable (all libraries must be ported for the application to be ported). It can also be difficult to ''track down all the dependencies'', which can be fixed by having a repository (see below). This is partly inevitable; an application built on a given ] (such as ]) 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 ]), or a simple application relies on many libraries. : An application depends on many ], 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 ] (such as ]) 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 ]), or a simple application relies on many libraries.<ref name="jamesdonald">{{Cite web
| last = Donald

| first = James
; Internet access hell
| title = Improved Portability of Shared Libraries
: In some ]s, you need to install new packages to configure Internet access, but you need Internet access to download the packages. This is circular dependency hell (a form of a ]).
| archiveurl=https://web.archive.org/web/20070926130800/http://www.princeton.edu/~jdonald/research/shared_libraries/cs518_report.pdf

| archivedate=2007-09-26
; long chains of dependencies
| publisher = Princeton University
: <tt>app</tt> depends on <tt>liba</tt>, which depends on <tt>libb</tt>, ..., which depends on <tt>libz</tt>. This is distinct from "many dependencies" if the dependencies must be resolved manually (e.g., on attempting to install <tt>app</tt>, you are prompted to install <tt>liba</tt> first. On attempting to install <tt>liba</tt>, you are ''then'' prompted to install <tt>libb</tt>.), otherwise it is equivalent to "many dependencies". This 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.
| date = 2003-01-25

| url = http://www.princeton.edu/~jdonald/research/shared_libraries/cs518_report.pdf
; conflicting dependencies
| accessdate = 2010-04-09}}</ref>
: If <tt>app1</tt> depends on <tt>libfoo 1.2</tt>, and <tt>app2</tt> depends on <tt>libfoo 1.3</tt>, and different versions of <tt>libfoo</tt> cannot be simultaneously installed, then <tt>app1</tt> and <tt>app2</tt> cannot simultaneously be used (or installed, if the installer checks dependencies). This can be solved by allowing simultaneous installation of different library versions.
; 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
; circular dependencies
| title = It's Good Work When You Can Find It; The Dependency Carousel
: If <tt>appX, version 1</tt> depends on <tt>app2</tt>, which depends on <tt>app3</tt>, which depends on <tt>app4</tt>, which depends on the original <tt>appX, version 0</tt>, then, in systems such as RPM or dpkg, the user must install all packages simultaneously - hence on Linux circular dependencies are often the result of a user misunderstanding the packaging system. On other platforms, however, the packaging system won't be able to resolve itself.
| 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 ]. 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 ] (e.g. the ]), on which thousands of packages depend. If this happens, the user will be prompted to uninstall all of those packages.
; ]
: 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. ]), but this is unlikely since major package managers have matured and official repositories are well maintained. This is the case with current releases of ] and major derivatives such as ]. Dependency hell, however, can result from installing a package directly via a package installer (e.g. ] or ]).
;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 ]<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 ] and ].


== Solutions == == Solutions ==


; Removing dependencies
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 '']''), and also a subnumber for each revision (aka '']''), e.g.: '''10'''.1, or 5.'''7'''. The major version only changes when programs that used that version will no longer be ]. 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 (greater than or equal to a particular minor version). As such, they will continue to work, and dependencies will be resolved successfully, even if the minor version changes.
: Many software libraries are written in a generous way, in an attempt to fulfill most users' needs, but sometimes only a small portion of functions are required in the host code. By examining the source, the functionality can be rewritten in a much more compact way (with respect to the license). In general, this can significantly reduce the application code, reduce later maintenance costs, and improve the software writing skills of programmers.


; Version numbering
Some ]s can perform smart upgrades, in which interdependent software components are upgraded at the same time, thereby resolving the major number incompatibility issue too.
: A very common solution to this problem is to have a standardized numbering system, wherein software uses a specific number for each version (aka '']''), and also a subnumber for each revision (aka '']''), 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 (greater than or equal to a particular minor version). As such, they will continue to work, and dependencies will be resolved successfully, even if the minor version changes. Semantic Versioning (aka "SemVer"<ref>{{cite web|url=https://semver.org|title=Project website: semver.org}}</ref>) is one example of an effort to generate a technical specification that employs specifically formatted numbers to create a software versioning scheme.
;Private per application versions
: ] introduced in ] prevented applications from overwriting system DLLs. Developers were instead encouraged to use "Private DLLs", copies of libraries per application in the directory of the application. This uses the Windows search path characteristic that the local path is always prioritized before the system directory with the system wide libraries. This allows easy and effective shadowing of library versions by specific application ones, therefore preventing dependency hell.<ref name="endofdllhell">{{cite web
| url=http://msdn.microsoft.com/library/techart/dlldanger1.htm
| title=The End of DLL Hell
| date=2000-01-11
| archiveurl=https://web.archive.org/web/20010605023737/http://msdn.microsoft.com/library/techart/dlldanger1.htm
| archivedate=2001-06-05
| last=Anderson
| first=Rick
| publisher=microsoft.com
| accessdate=2010-07-07
}}</ref>
: PC-BSD, up to and including version 8.2, a predecessor of ] (an operating system based on ]) places packages and dependencies into self-contained directories in ''/Programs'', which avoids breakage if system libraries are upgraded or changed. It uses its own "PBI" (Push Button Installer) for package management.<ref></ref>
; Side-by-side installation of multiple versions
: The version numbering solution can be improved upon by elevating the version numbering to an operating system supported feature. This allows an application to request a module/library by a unique name ''and'' version number constraints, effectively transferring the responsibility for brokering library/module versions from the applications to the operating system. A shared module can then be placed in a central repository without the risk of breaking applications which are dependent on previous or later versions of the module. Each version gets its own entry, side by side with other versions of the same module.
: This solution is used in ] operating systems since Windows Vista, where the ] is an implementation of such a central registry with associated services and integrated with the installation system/package manager. ] solves this problem with a concept called slotting, which allows multiple versions of shared libraries to be installed.<ref> on gentoo.org</ref>
; Smart package management
: Some ]s 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 ] distributions have also implemented ]-based package management systems to try to solve the dependency problem. These systems are a layer on top of the ], ], or other packaging systems that are designed to automatically resolve dependencies by searching in predefined ]. Examples of these systems include ], ], ], ], ], ] and others. Typically, the software repositories are ] sites or websites, ] on the local computer or shared across a ] 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 ] 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.<ref name="linuxdependencyhell">{{cite web |url=http://archive09.linux.com/feature/155922 |title=Nix fixes dependency hell on all Linux distributions |author=Pjotr Prins |author2=Jeeva Suresh |author3=Eelco Dolstra |name-list-style=amp |date=2008-12-22 |accessdate=2013-05-22 |publisher=linux.com |quote=''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.'' |archive-url=https://web.archive.org/web/20150708101023/http://archive09.linux.com/feature/155922 |archive-date=2015-07-08 |url-status=dead }}</ref>
; Installer options
: Because different pieces of software have different dependencies, it is possible to get into a ] of dependency ]s, or an ever-expanding ] of requirements, as each new package demands several more be installed. Systems such as Debian's ] can resolve this by presenting the user with a range of solutions, and allowing the user to accept or reject the solutions, as desired.
; Easy adaptability in programming
: If application software is designed in such a way that its programmers are able to easily adapt the interface layer that deals with the OS, window manager or desktop environment to new or changing standards, then the programmers would only have to monitor notifications from the environment creators or component library designers and quickly adjust their software with updates for their users, all with minimal effort and a lack of costly and time-consuming redesign. This method would encourage programmers to pressure those upon whom they depend to maintain a reasonable notification process that is not onerous to anyone involved.
; Strict compatibility requirement in code development and maintenance
: If the applications and libraries are developed and maintained with guaranteed downward compatibility in mind, any application or library can be replaced with a newer version at any time without breaking anything. While this does not alleviate the multitude of dependency, it does make the jobs of package managers or installers much easier.
; ]s
: Another approach to avoiding dependency issues is to deploy applications as a ]. A software appliance encapsulates dependencies in a pre-integrated self-contained unit such that users no longer have to worry about resolving software dependencies. Instead the burden is shifted to developers of the software appliance. ] and their images (such as those provided by ] and Docker Hub) can be seen as an implementation of software appliances.
; ]s
: An application (or version of an existing conventional application) that is completely self-contained and requires nothing to be already installed. It is coded to have all necessary components included, or is designed to keep all necessary files within its own directory, and will not create a dependency problem. These are often able to run independently of the system to which they are connected. Applications in ] and the ] for Linux use ], which work in much the same way: programs and their dependencies are self-contained in their own directories (folders).<ref>{{cite web
| url=http://rox.sourceforge.net/desktop/AppDirs.html
| title=Application directories
| accessdate=7 September 2013
}}</ref>
: This method of distribution has also proven useful when porting applications designed for Unix-like platforms to Windows, the most noticeable drawback being multiple installations of the same ]. For example, Windows installers for ], ], and ] all include identical copies of the ] toolkit, which these programs use to render widgets. On the other hand, if different versions of GTK are required by each application, then this is the correct behavior and successfully avoids dependency hell.


==Platform-specific==
Many current ] ]s have also implemented ]-based package management systems to try to solve the dependency problem. These systems are a layer on top of the ], ], or other packaging systems that are designed to automatically resolve dependencies by searching in predefined software repositories. Typically these software repositories are ] sites or websites, ] on the local computer or shared across a ] 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 ] 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 ], ], ], ] and others.
On specific ]s, "dependency hell" often goes by a local specific name, generally the name of components.


* ]{{snd}} a form of dependency hell occurring on 16-bit ].
Because different pieces of software have different dependencies, it is possible to get into a ] of dependency ]s, or (possibly worse) an ever-expanding ] of requirements, as each new package demands several more be installed. Systems such as Debian's ] can resolve this by presenting the user with a range of solutions, and allowing the user to accept or reject the solutions, as desired.
* ]{{snd}} a form of dependency hell occurring on the ].
The Haskell Compiler GHC is an example of a circular dependency. To compile it, you need GHC.
* ]{{snd}} a form of dependency hell occurring in the ] before build tools like ] solved this problem in 2004.{{citation needed|date=March 2017}}
It can be solved by downloading a binary version of GHC, and compiling the new version of GHC with this binary version.
* RPM hell{{snd}} a form of dependency hell occurring in the ] distribution of ] and other distributions that use ] as a package manager.<ref name="linuxcompa">{{cite web

| title = Is Linux Annoying?
=== Software appliances ===
| last = Weinstein

| first = Paul
One of the benefits of deploying an application as a ] is that a software appliance encapsulates dependencies in a pre-integrated self-contained unit. Users no longer have to worry about resolving software dependencies, only the developer of the appliance, and only once.
| url = http://linuxdevcenter.com/pub/a/linux/2003/09/11/linux_annoyances.html

| publisher = linuxdevcenter.com
== Examples ==
| date = 2003-09-11
James Donald, in his 2003 paper titled ''Improved Portability of Shared Libraries'' argued that dependency hell is worse under ] than Microsoft Windows. Several ]s have had problems with software not packaged for the distribution when updating libraries, since the ]s of some Open Source libraries are prone to change between releases.
| accessdate = 2010-04-10}}</ref>

A modern example of dependency hell on Microsoft Windows, Linux, and Mac OS X is the ] or GRE used by ] projects. Each product released from the Mozilla foundation includes its own version of the complete Gecko Runtime Engine, due to the volatile nature of the programming interfaces used. Thus, if a user installs ], ], and ], there will be three copies of GRE on the machine. These may or may not be compatible, depending on when the GRE ] was ]. Some external projects like ] depend on specific versions of the ] to use GRE, and break if a different version is installed; while others such as ] bring their own copy of GRE. Observe that the duplication of the GRE is actually a work-around to the core problem of dependency hell.

By ] Gecko, the Mozilla developers avoid potential dependency hell, at the cost of increased disk usage.
Given the fact that harddisk<!-- disk /=/ harddisc --> space comes quite cheap these days, static linking in itself is not so bad. Tools such as bash or make that are statically linked will never complain about a missing shared object when the c library (glibc) is upgraded.
Both approaches have advantages and disadvantages.


== See also == == See also ==
* ] – a situation in which solving a problem depends on contradictory circumstances, named after a concept described in a 1961 novel
* ] - software appliances can be used to prevent dependency hell
* ]{{snd}} techniques and tools for managing software versions
* ] - Forms of dependency among software artifacts
* ]{{snd}} forms of dependency among software artifacts
* ] - Techniques and tools for managing software versions
* ]
* ], ] and ]
* ]
* ]
* ]
* ]
* ]
* ]
* ]


== References == == References ==
{{reflist|30em}}
*
* .
* .
== External links ==
* .
*
*
]
]
]


]
]
]
]
]
]

Latest revision as of 15:27, 14 January 2025

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Dependency hell" – news · newspapers · books · scholar · JSTOR (August 2024) (Learn how and when to remove this message)
Colloquial term for software requiring many conflicting 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.

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.

Problems

Dependency hell takes several forms:

Many dependencies
An application depends on many 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) 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.
Long chains of dependencies
If 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 (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 app1 depends on libfoo 1.2, and app2 depends on libfoo 2.0, 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 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 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.
Package manager dependencies
It is possible for dependency hell to result from installing a prepared package via a package manager (e.g. 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. Dependency hell, however, can result from installing a package directly via a package installer (e.g. 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 are prone to have conflicts between packages of their repositories, causing dependency hell in Linux distributions such as CentOS and Red Hat Enterprise Linux.

Solutions

Removing dependencies
Many software libraries are written in a generous way, in an attempt to fulfill most users' needs, but sometimes only a small portion of functions are required in the host code. By examining the source, the functionality can be rewritten in a much more compact way (with respect to the license). In general, this can significantly reduce the application code, reduce later maintenance costs, and improve the software writing skills of programmers.
Version numbering
A very common solution to this problem is to have a standardized 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 (greater than or equal to a particular minor version). As such, they will continue to work, and dependencies will be resolved successfully, even if the minor version changes. Semantic Versioning (aka "SemVer") is one example of an effort to generate a technical specification that employs specifically formatted numbers to create a software versioning scheme.
Private per application versions
Windows File Protection introduced in Windows 2000 prevented applications from overwriting system DLLs. Developers were instead encouraged to use "Private DLLs", copies of libraries per application in the directory of the application. This uses the Windows search path characteristic that the local path is always prioritized before the system directory with the system wide libraries. This allows easy and effective shadowing of library versions by specific application ones, therefore preventing dependency hell.
PC-BSD, up to and including version 8.2, a predecessor of TrueOS (an operating system based on FreeBSD) places packages and dependencies into self-contained directories in /Programs, which avoids breakage if system libraries are upgraded or changed. It uses its own "PBI" (Push Button Installer) for package management.
Side-by-side installation of multiple versions
The version numbering solution can be improved upon by elevating the version numbering to an operating system supported feature. This allows an application to request a module/library by a unique name and version number constraints, effectively transferring the responsibility for brokering library/module versions from the applications to the operating system. A shared module can then be placed in a central repository without the risk of breaking applications which are dependent on previous or later versions of the module. Each version gets its own entry, side by side with other versions of the same module.
This solution is used in Microsoft Windows operating systems since Windows Vista, where the Global Assembly Cache is an implementation of such a central registry with associated services and integrated with the installation system/package manager. Gentoo Linux solves this problem with a concept called slotting, which allows multiple versions of shared libraries to be installed.
Smart package management
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. Examples of these systems include Apt, Yum, Urpmi, ZYpp, Portage, Pacman and others. Typically, the 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.
Installer options
Because different pieces of software have different dependencies, it is possible to get into a vicious circle of dependency requirements, or an ever-expanding tree of requirements, as each new package demands several more be installed. Systems such as Debian's Advanced Packaging Tool can resolve this by presenting the user with a range of solutions, and allowing the user to accept or reject the solutions, as desired.
Easy adaptability in programming
If application software is designed in such a way that its programmers are able to easily adapt the interface layer that deals with the OS, window manager or desktop environment to new or changing standards, then the programmers would only have to monitor notifications from the environment creators or component library designers and quickly adjust their software with updates for their users, all with minimal effort and a lack of costly and time-consuming redesign. This method would encourage programmers to pressure those upon whom they depend to maintain a reasonable notification process that is not onerous to anyone involved.
Strict compatibility requirement in code development and maintenance
If the applications and libraries are developed and maintained with guaranteed downward compatibility in mind, any application or library can be replaced with a newer version at any time without breaking anything. While this does not alleviate the multitude of dependency, it does make the jobs of package managers or installers much easier.
Software appliances
Another approach to avoiding dependency issues is to deploy applications as a software appliance. A software appliance encapsulates dependencies in a pre-integrated self-contained unit such that users no longer have to worry about resolving software dependencies. Instead the burden is shifted to developers of the software appliance. Containers and their images (such as those provided by Docker and Docker Hub) can be seen as an implementation of software appliances.
Portable applications
An application (or version of an existing conventional application) that is completely self-contained and requires nothing to be already installed. It is coded to have all necessary components included, or is designed to keep all necessary files within its own directory, and will not create a dependency problem. These are often able to run independently of the system to which they are connected. Applications in RISC OS and the ROX Desktop for Linux use application directories, which work in much the same way: programs and their dependencies are self-contained in their own directories (folders).
This method of distribution has also proven useful when porting applications designed for Unix-like platforms to Windows, the most noticeable drawback being multiple installations of the same shared libraries. For example, Windows installers for gedit, GIMP, and HexChat all include identical copies of the GTK toolkit, which these programs use to render widgets. On the other hand, if different versions of GTK are required by each application, then this is the correct behavior and successfully avoids dependency hell.

Platform-specific

On specific computing platforms, "dependency hell" often goes by a local specific name, generally the name of components.

See also

References

  1. Michael Jang (2006). Linux annoyances for geeks. O'Reilly Media. p. 325. ISBN 9780596552244. Retrieved 2012-02-16.
  2. Donald, James (2003-01-25). "Improved Portability of Shared Libraries" (PDF). Princeton University. Archived from the original (PDF) on 2007-09-26. Retrieved 2010-04-09.
  3. Stevens, Al (2001-05-01). "It's Good Work When You Can Find It; The Dependency Carousel". J-DDJ. 26 (5). www.drdobbs.com/blog: 121–124. ISSN 1044-789X. Archived from the original on 2011-08-11. Retrieved 2010-04-10.
  4. ^ Pjotr Prins; Jeeva Suresh & Eelco Dolstra (2008-12-22). "Nix fixes dependency hell on all Linux distributions". linux.com. Archived from the original on 2015-07-08. Retrieved 2013-05-22. 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.
  5. "Yum Dependency Hell". Archived from the original on 2016-12-19. Retrieved 2015-12-28.
  6. "Project website: semver.org".
  7. Anderson, Rick (2000-01-11). "The End of DLL Hell". microsoft.com. Archived from the original on 2001-06-05. Retrieved 2010-07-07.
  8. pbiDIR
  9. Slotting on gentoo.org
  10. "Application directories". Retrieved 7 September 2013.
  11. Weinstein, Paul (2003-09-11). "Is Linux Annoying?". linuxdevcenter.com. Retrieved 2010-04-10.
Categories: