When a package manager plans an install or an upgrade on a Debian- or RPM-based Linux host, what problem is its dependency solver actually solving, and what does it mean when it reports unmet or broken dependencies?

## What a package actually declares A package does not carry its dependencies; it carries *assertions about names*. Two families of assertion matter. **Requirements.** Debian's `Depends` means "this must be installed and configured before I am configured"; `Pre-Depends` is stronger and constrains unpack ordering too. RPM's `Requires` is the equivalent. Both accept version ranges: `libssl3 (>= 3.0.0)`. **Negative relationships.** Debian's `Conflicts` means the two packages cannot be installed together; `Breaks` is a weaker statement that a specific version of another package stops working; `Replaces` declares that this package takes over files or the role of another. RPM has `Conflicts`, and `Obsoletes`, which means "when upgrading, remove that package and take its place" — the mechanism behind package renames. **Virtual names.** Both ecosystems have `Provides`: a package may declare that it provides `mail-transport-agent` or `webserver`, and other packages may depend on that abstract name. Several real packages can provide the same virtual name, so the solver may have a genuine choice to make. RPM pushes this further with **automatically generated dependencies**. At build time the tooling inspects the binaries and emits requirements on shared-library sonames with symbol versions, such as `libc.so.6(GLIBC_2.34)(64bit)`, and matching `Provides` on the packages that ship those libraries. Debian achieves comparable granularity through `shlibs`/`symbols` metadata that turns a link-time dependency into a versioned `Depends`. This is why upgrading a core library can cascade across hundreds of packages: the graph really is that dense. ## The solve Given the currently installed set, the set of packages available in every enabled repository, and your request, the solver must choose an assignment — install, upgrade, downgrade, remove, or leave alone, for each package — such that all positive requirements hold and no negative relationship is violated. That is boolean satisfiability. It is NP-hard in general, and real distributions have tens of thousands of packages, so solvers use dedicated engines: `dnf` and `zypper` both build on **libsolv**, a SAT solver specialised for this problem, while APT uses its own resolver. Practical consequences follow: - There may be **several valid solutions**, and the solver applies policy — prefer the newest version, prefer keeping what is installed, prefer the higher-priority repository — to choose among them. - The solver may propose actions you did not ask for: removing a package because something else `Obsoletes` it, or downgrading, or pulling in a large dependency chain. That is not a bug; it is the only assignment it found. - Failure messages can be long, because explaining *why* no solution exists means quoting the chain of constraints that collide. ``` # The shape of an unsatisfiable report # nothing provides libfoo.so.2()(64bit) needed by myapp-2.0-1.x86_64 ``` ## Unmet vs broken These are different states and the fixes differ. **Unmet / unsatisfiable** is a statement about the *universe the solver can see*. The dependency exists somewhere in the world but not in any enabled repository. Common causes: - a required repository was never enabled, or its metadata is stale, - packages from two different distribution releases or two third-party repositories are being mixed, so their library versions cannot coexist, - a package has been pinned or held at a version that blocks the rest of the graph, - the package was built for a different release than the host runs. The fix is always to change what the solver can see, or to relax the constraint you imposed — never to force the install. **Broken local state** is a statement about the *host's database*. On Debian systems, a maintainer script that exits non-zero leaves a package unpacked but unconfigured; further transactions then refuse to proceed until that is resolved. The files may be present while the package is, formally, not installed. Recovery means completing the configuration step or removing the offending package, after fixing whatever made the script fail — often a missing user, a full filesystem, or a service that would not start. ## Conflicts you meet in practice - **File conflicts.** Two packages ship the same path. The low-level installer detects this at unpack time and aborts, because file ownership must be unique. Legitimate cases are declared with `Replaces`/`Obsoletes`; undeclared ones mean two repositories are shipping overlapping builds of the same software. - **Mixing releases.** Pulling a single newer package from a newer suite drags in a newer libc, which every other package's constraints then reject. The graph is release-wide; there is no such thing as upgrading one package "in isolation" once shared libraries are involved. - **Third-party repositories that shadow distribution packages.** When a vendor repository ships its own build of a common library at a different version, the solver may be forced into a choice that quietly replaces distribution packages. Repository priorities exist to prevent that. ## How to reason about a failure Read the error as a constraint chain and identify which of three things is true: the needed thing is not available anywhere the host can see; something you configured (a hold, a pin, an exclude, a priority) is forbidding the solution; or the local database is already inconsistent from a previous failed transaction. Nearly every real incident is one of those three, and forcing past the error converts a solvable planning problem into a corrupted inventory.