Debian’s package manager APT is famous for its inter-package dependency resolving mechanism:
Long before rpm
based distributions learned how to install dependant packages automatically Debian did do this for many years.
You simply can install a high-level package using apt-get install $pkg
, which will then automatically resolve all dependencies:
Dependant packages are downloaded and install along automatically.
This works very well when you just use packages from a single consistent source like the stable Debian repository.
It mostly also works with multiple repositories, but from time to time the resolver does strange things.
Here at Univention GmbH we build our own packages.
Therefore it is essential for our customers that we get the dependencies right.
Today we had the strange behavior, where one of our packages could not be upgraded:
APT decided to refuse the package from getting installed.
Simplify specifying one additional dependency on the command line made it work.
So what happened and why did APT refuse the initial command?
Resolver
Dependency resolution has some very useful information on how the resolver works:
APT works in its internal resolver in two stages:
First all packages are visited and marked for installation, keep back or removal. Option Debug::pkgDepCache::Marker
shows this.
This also decides which packages are to be installed to satisfy dependencies, which can be seen by Debug::pkgDepCache::AutoInstall
.
After this is done, we might be in a situation in which two packages want to be installed, but only one of them can be.
It is the job of the pkgProblemResolver
to decide which of two packages ‘wins’ and can therefore decide what has to happen.
You can see the contenders as well as their fight and the resulting resolution with Debug::pkgProblemResolver
.