Dependency Hell - Problems

Problems

Dependency hell takes several forms:

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 locate all the dependencies, which can be fixed by having a repository (see below). This is partly inevitable; an application built on a given 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 refactoring), or a simple application relies on many libraries.

long chains of dependencies

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, you are prompted to install liba first. On attempting to install liba, you are then prompted to install libb.). 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

If 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 or even supposed to work) is that the resulting long chain of dependencies may lead to a conflicting version of glibc, the single most important library. If this happens, the user will be prompted to uninstall thousands of packages.

circular dependencies

If appX, version 1 depends on app2, which depends on app3, which depends on app4, which depends on the original appX, version 0, 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 may not be able to resolve the circular dependency.

Arbitrary dependencies

This is common in systems like Ubuntu that use apt and .deb package management, but can apply to other distributions as well. This is where package maintainers make random or unnecessary packages a dependency for a package that does not need them. For example, if you wanted to remove one program (Say Chromium), it would then remove your network manager or wifi capability by making Chromium a dependency of the network manager even though the network manager does not require Chromium to run. This can sometimes be a trick to install malware, or a tactic used by developers to control the habits of their users.