Si la dependencia es una recomendación, aptitude intentará ver si es una recomendación “nueva” o una “recomendación” ya “satisfecha”. aptitude considera una recomendación como “nueva” si el paquete manifestando la recomendación no está instalado, o si la versión instalada no recomienda un paquete del mismo nombre. Por otro lado, una recomendación está “satisfecha” si el paquete ya instalado recomienda un paquete del mismo nombre, estando ya satisfecho.

Por ejemplo: imagine que la versión 1.0 de prog recomienda la versión 4.0 de libcool1, pero la versión 2.0 de prog recomienda la versión 5.0 de libcool1, y también recomienda apache. Si escogiese actualizar prog de la versión 1.0 a la versión 2.0, la recomendación de apache se considerará “nueva” porque la versión 1.0 de prog no recomendaba apache. Por otro lado, la recomendación de libcool1 no es “nueva”, porque la versión1.0 de prog recomienda libcool1, aunque recomiende una versión diferente. De todas formas, si libcool1 está instalado, entonces la recomendación se tratará como “ya satisfecha”.

Si la opción de configuración APT::Install-Recommends es true, aptitude siempre intentará satisfacer las recomendaciones nuevas y ya satisfechas; todas las demás se ignorarán en la siguiente resolución. Si la opción es false, la resolución inmediata de dependencias ignorará todas las recomendaciones.

Si la dependencia se da en varios paquetes en combinación con «OR», examine cada una de las alternativas en el orden dado. Por ejemplo, si un paquete depende de “exim | mail-transport-agent”, aptitude procesará primero exim, y después mail-transport-agent.

Intente resolver cada alternativa dada. Si la dependencia es un conflicto, elimine la alternativa actual si ya está instalada (y por cada conflicto no de versiones, elimine también cualquier paquete que provoca el núcleo del conflicto). También puede instalar la versión candidata de la alternativa actual si satisface la dependencia. Si no, o si no hay otra versión candidata (p. ej., porque la alternativa actual es un paquete virtual), y si la dependencia no tiene versión, intente instalar el paquete de más alta prioridad^[12] cuya versión candidata provea el objetivo de la alternativa actual.

Por ejemplo, imagine que estamos intentando resolver “Depende: exim | mail-transport-agent”. En primer lugar, aptitude intentará instalar el paquete exim. Si exim no está disponible, aptitude intentará entonces instalar el paquete con la prioridad más alta cuya versión candidata provee exim. Si no encuentra tal paquete, aptitude instalará el paquete con la prioridad más alta cuya versión candidata provee el paquete virtual mail-transport-agent. Por otro lado, imagine que la dependencia es “Depende: exim (>= 2.0.0) | mail-transport-agent”, pero cuya única versión de exim disponible es 1.0. En este caso, aptitude no instalará exim (porque la versión no corresponde a la dependencia), ni intentará instalar paquetes que provean exim (porque los paquetes virtuales no pueden satisfacer una dependencia con una restricción en cuanto a la versión). Por ello, aptitude le instalaría el paquete con la prioridad más alta cuya versión candidata provea mail-transport-agent.

Si el paquete se instaló siguiendo el paso anterior, resuelve sus dependencias empleando este algoritmo, y finaliza entonces.