| Immediate dependency resolution | ||
|---|---|---|
 | Resolving package dependencies |  |
| Immediate dependency resolution | ||
|---|---|---|
| | Resolving package dependencies | |
Whenever you choose to install or upgrade a package in aptitude, aptitude makes an immediate attempt to resolve any of its dependencies that are not fulfilled. For each unsatisfied dependency (either a 「Depends」, a 「Recommends」, or a 「Conflicts」), it performs the following steps:
If the dependency is a recommendation, aptitude tries to guess whether it is a 「new」 recommendation or a 「previously satisfied」 recommendation. aptitude considers a recommendation to be 「new」 if the package declaring the recommendation is not currently installed, or if its installed version does not recommend a package of the same name. On the other hand, a recommendation is 「previously satisfied」 if the package declaring the recommendation is installed, the currently installed version recommends a package of the same name, and that recommendation is currently fulfilled.
For example: suppose that version 1.0 of
prog recommends version 4.0 of
libcool1, but version 2.0 of
prog recommends version 5.0 of
libcool1, and also recommends apache.
If you choose to upgrade prog from version
1.0 to version 2.0, the recommendation
of apache will be considered to be 「new」
because version 1.0 of prog did not
recommend apache. On the other hand, the recommendation
of libcool1 is not
「new」, because version 1.0 of
prog recommended libcool1, even though
it recommended a different version. However, if libcool1
is installed, then that recommendation will be considered to be
「previously satisfied」.
If the configuration option APT::Install-Recommends
is true, aptitude will always attempt to fulfill
「new」 and 「previously satisfied」 recommendations;
all others will be ignored by immediate resolution. If that option is
false, immediate dependency resolution will ignore
all recommendations.
If the dependency is on several packages combined with OR, examine each of
the alternatives in the order that they are given. For instance, if a
package depends on 「exim |
mail-transport-agent」, aptitude will first process
exim, then mail-transport-agent.
For each alternative, attempt to resolve it. If the dependency is a conflict, remove the current alternative if it is installed (and for an unversioned conflict, also remove any package providing the target of the conflict). Otherwise, install the candidate version of the current alternative if it satisfies the dependency. If not, or if there is no candidate version (for instance, because the current alternative is a virtual package), and if the dependency is unversioned, attempt to install the highest-priority package[12] whose candidate version provides the target of the current alternative.
For instance, say we are attempting to resolve 「Depends: exim
| mail-transport-agent」. aptitude will first attempt to
install the package exim. If exim is
not available, aptitude will then attempt to install the highest-priority
package whose candidate version provides exim. If there
is no such package, aptitude will install the highest-priority package
whose candidate version provides the virtual package
mail-transport-agent. On the other hand, suppose that
the dependency is 「Depends: exim (>= 2.0.0) |
mail-transport-agent」, but only version
1.0 of exim is available. In this
case, aptitude will not install exim (because the
version does not match), nor will it attempt to install packages providing
exim (because virtual packages cannot match a dependency
with a version restriction). Thus, aptitude will fall back to installing
the highest-priority package whose candidate version provides
mail-transport-agent.
If a package was installed by the previous step, resolve its dependencies using this algorithm, then stop.
While this technique very often solves all the outstanding package dependencies, it can fail in a number of common circumstances.
Conflicts are resolved by removing the package that is the target of the conflict. But now other packages that depend on this package have unresolved dependencies; the immediate resolver makes no attempt to fix them.
A dependency might not be satisfiable due to version restrictions and due to
the limitation that only candidate versions are considered. For instance,
say that versions 1.0 and 2.0 of
fileutils are available, that the candidate version is
1.0, and that the package octopus
declares a dependency 「Depends: fileutils (>=
2.0)」. Immediate resolution is unable to resolve this
dependency: it will never consider version 2.0 of the
package, since that is not the candidate version.
The interactive dependency resolver can solve these situations and more. When there are broken dependencies left over, or when immediate dependency resolution is disabled, the interactive resolver will automatically start searching for a solution. The next section describes how to use the interactive dependency resolver.
| |  | |
| Dependency resolution in aptitude |  | Resolving Dependencies Interactively |