Если зависимость является рекомендацией, aptitude пытается определить, является она «новой» рекомендацией, или «ранее удовлетворённой» рекомендацией. aptitude рассматривает рекомендацию в качестве «новой», если пакет, объявляющий эту рекомендацию, в настоящее время не установлен, или если установленная версия данного пакета не рекомендует пакет с тем же именем. С другой стороны, рекомендация является «ранее удовлетворённой», если пакет, объявляющий эту рекомендацию, установлен, установленная в настоящее время версия этого пакета рекомендует пакет с тем же именем, и эта рекомендация в настоящее время удовлетворена.

Например: допустим, что версия 1.0 пакета prog рекомендует версию 4.0 пакета libcool1, но версия 2.0 пакета prog рекомендует версию 5.0 пакета libcool1, а также рекомендует пакет apache. Если вы выберите обновление пакета prog с версии 1.0 до версии 2.0, рекомендация пакета apache будет рассматриваться в качестве «новой», поскольку версия 1.0 пакета prog не рекомендовала пакет apache. С другой стороны, рекомендация пакета libcool1 не является «новой», так как версия 1.0 пакета prog рекомендовала пакет libcool1, даже несмотря на то, что она рекомендовала другую версию. Тем не менее, если пакет libcool1 установлен, эта рекомендация будет рассматриваться в качестве «ранее удовлетворённой».

Если параметр настройки APT::Install-Recommends имеет значение true, то aptitude всегда будет пытаться удовлетворить «новые» и «ранее удовлетворённые» рекомендации; все остальные будут игнорироваться непосредственным решением. Если этот параметр имеет значение false, все рекомендации будут игнорироваться алгоритмом непосредственного разрешения зависимостей.

Если зависимость от нескольких пакетов составлена с применением ИЛИ, рассматривается каждая альтернатива в том порядке, в каком они даны. Например, если пакет зависит от «exim | mail-transport-agent», aptitude в первую очередь рассмотрит пакет exim, а затем mail-transport-agent.

Попытаться разрешить зависимость для каждой альтернативы. Если зависимость является конфликтом, удалить текущую альтернативу, если она установлена (и для конфликта без версии, также удалить всякий пакет, предоставляющий цель конфликта). В противном случае, установить версию-кандидат текущей альтернативы, если она разрешает зависимость. Если же нет, или если нет версии-кандидата (например потому, что текущая альтернатива является виртуальным пакетом), и если зависимость указана без версии, то попытаться установить пакет с наивысшим приоритетом^[12], чья версия-кандидат предоставляет цель текущей альтернативы.

Например, мы пытаемся разрешить зависимость «Зависит: exim | mail-transport-agent». aptitude в первую очередь попытается установить пакет exim. Если пакет exim не доступен, aptitude попытается установить пакет с наивысшим приоритетом, чья версия-кандидат предоставляет exim. Если такого пакета нет, aptitude установит пакет с наивысшим приоритетом, чья версия-кандидат предоставляет виртуальный пакет mail-transport-agent. С другой стороны, допустим, что эта зависимость имеет вид «Зависит: exim (>= 2.0.0) | mail-transport-agent», но доступна лишь версия 1.0 пакета exim. В этом случае, aptitude не будет устанавливать exim (поскольку его версия не подходит), и не будет пытаться установить пакеты, предоставляющие exim (так как виртуальные пакеты не могут подойти для разрешения зависимости с ограничением версии). Таким образом, aptitude прибегнет к установке пакета с наивысшим приоритетом, чья версия-кандидат предоставляет mail-transport-agent.

Если пакет был установлен на предыдущем шаге, разрешить его зависимости, используя этот алгоритм, затем остановиться.