|
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. Often, rather than 'reinventing the wheel', software is designed to leverage other software components that are already available, or have already been designed and implemented for use elsewhere. This could be compared to how a person building a house might buy off-the-shelf components, such as bricks, windows, and doors, rather than building everything themself. Even for a builder, it can be a problem if a building is designed for a modern door, and only older doors with different specifications are available. However, in the software world, where components evolve rapidly, and components often cross-depend on other components, this problem is more pronounced. On some specific computing platforms, this problem may go by another name, reflecting the specific packages or software that has a dependency conflict. For example, on Windows, the term DLL hell is used, reflecting the fact that most problems occur when a program tries to access an underlying DLL software component. The issue of dependency hell may be regarded as an anti-pattern, where the fault lies less with the suppliers of the products than with the framework into which they have to fit. The most obvious (and very common) solution to this problem is to have a standardised numbering system, wherein software uses a specific number for version (aka major version), and also a subnumber for the revision (aka minor version), such as 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 correction 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. As such, they will continue to work, and dependencies will be resolved successfully, even if the minor version changes. 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 or dpkg packaging systems that is designed to automatically resolve dependencies by searching in predefined software repositories. Typically these 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. Encountering the problem is quite rare in the case of Debian-based distributions, however. In all cases, dependency hell is still faced by the repository maintainers. Examples of these systems include Apt, Yum, Urpmi, emerge and others. Because different pieces of software have different dependencies, 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. Systems such as Debian's APT can resolve this by presenting the user with a range of solutions, and allowing the user to accept or reject the solutions they prefer or dislike, respectively.
Package Managers See also | ||||||||
|
| |||||||||
 |
|
| |