Editing Dependency hell (section)

== 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 ''[[Software versioning|major version]]''), and also a subnumber for each revision (aka ''[[Maintenance release|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"<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
: [[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.<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 [[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.<ref>{{Webarchive|url=https://web.archive.org/web/20130327233344/http://www.pbidir.com/|date=2013-03-27|title=pbi Directory}}</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 [[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.<ref>{{Cite web |title=Slotting |url=https://devmanual.gentoo.org/general-concepts/slotting/index.html |access-date=2025-03-10 |website=gentoo.org}}</ref>
; Smart package management
: Some [[package manager]]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 [[Linux]] distributions have also implemented [[Version control|repository]]-based package management systems to try to solve the dependency problem. These systems are a layer on top of the [[RPM Package Manager|RPM]], [[dpkg]], or other packaging systems that are designed to automatically resolve dependencies by searching in predefined [[software repository|software repositories]]. Examples of these systems include [[Advanced Packaging Tool|Apt]], [[yum (software)|Yum]], [[Urpmi]], [[ZYpp]], [[Portage (software)|Portage]], [[Arch Linux#Pacman|Pacman]] and others. Typically, the software repositories are [[File Transfer Protocol|FTP]] sites or websites, [[Directory (computing)|directories]] on the local computer or shared across a [[computer network|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 [[Website#mirror site|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.<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 [[Virtuous circle and vicious circle|vicious circle]] of dependency [[requirement]]s, or an ever-expanding [[Tree structure|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 appliance]]s
: 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. [[Container (virtualization)|Containers]] and their images (such as those provided by [[Docker (software)|Docker]] and Docker Hub) can be seen as an implementation of software appliances.
; [[Portable application]]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 [[RISC OS]] and the [[ROX Desktop]] for Linux use [[application directory|application directories]], 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 [[Library (computing)#Shared libraries|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.