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.