Frequently Asked Question

What is dependency hell and how do package managers avoid it?

Dependency hell is the situation where two packages you want both work, but not at the same time: package A insists on version 2 of some shared library, package B insists on version 3, and the system can only have one. Worse cases involve cycles, A needs B, B needs C, C needs A at an incompatible version, or "diamond" dependencies where two independent libraries pull in different versions of a third. Before package managers, this was a routine experience on Unix systems and was the original motivation for dpkg and rpm.

Modern package managers avoid it in several ways. Distributions like Debian and RHEL freeze a coherent set of versions for years, with the maintainers' job being to ensure every package in the archive actually composes. Rolling-release distributions like Arch push everything forwards in lockstep so that conflicts never accumulate. Sandboxed formats (Flatpak, Snap) bundle their own runtime so they cannot conflict with the host. And Nix takes the most radical approach: it installs every version side by side in content-addressed paths, so two versions of the same library cannot collide by design.