Dependency hell is the name for what happens when the web of packages a program depends on cannot be satisfied all at once. The classic form is a version conflict: one library needs version 1 of a shared dependency, another needs version 2, and there is only room to install one. Deep chains and circular requirements make it worse, until producing a working install becomes a frustrating puzzle.
The problem is rooted in how dependencies are declared. The Debian reference manual documents the machinery a package system uses to keep installs consistent, describing dependency relationships such as “Depends” (an absolute dependency), “Conflicts” (an absolute incompatibility), and “Breaks” (an incompatibility tied to a specific version), and noting that package tools must “make package dependency resolution” before installing or upgrading (https://www.debian.org/doc/manuals/debian-reference/ch02.en.html). When those declared relationships cannot all be honored, resolution fails and the user lands in dependency hell.
The Debian docs also name a common trigger: mixing packages from different release lines. Running “stable release mixed with some packages from testing or unstable release is riskier than running pure unstable release for library version mismatch” (https://www.debian.org/doc/manuals/debian-reference/ch02.en.html). Pulling one package from a newer source can drag in a chain of incompatible requirements.
The Windows world had its own famous version of the problem. Microsoft’s documentation describes “DLL versioning problems”: if an application “depends on a specific version of a shared DLL, and another application is installed with a newer or older version of that DLL, then that can cause compatibility problems and instability” (https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection). That specific case became known as “DLL hell.” Modern tools fight dependency hell with isolation (per-project dependency trees), pinned versions, and lockfiles that record one resolved, working set.