Современные системы на базе Linux состоят из огромного числа разделяемых библиотек, исполняемых файлов, скриптов и т.д. Удаление или изменение версии одного из составляющих систему компонентов может повлечь неработоспособность других, связанных с ним компонентов, или даже вывести из строя всю систему. В контексте системного администрирования проблемы такого рода называют нарушением целостности системы, а задачу по обеспечению наличия в системе всех необходимых программных компонент согласованных версий — задачей обеспечения целостности системы.

Для целей поддержания целостности и обеспечения возможности распространения программ в двоичном виде в первую очередь стали использоваться менеджеры пакетов (такие, как RPM в дистрибутивах RedHat Linux или dpkg в Debian GNU/Linux). Менеджеры пакетов дают возможность унифицировать и автоматизировать сборку двоичных пакетов и облегчают их установку, позволяя проверять наличие необходимых для работы устанавливаемой программы компонент подходящей версии непосредственно в момент установки. Однако менеджеры пакетов оказались неспособны предотвратить все возможные коллизии при установке или удалении программ, а тем более эффективно устранить нарушения целостности системы. Особенно сильно этот недостаток сказывается при обновлении систем из централизованного репозитория пакетов, в котором последние могут непрерывно обновляться, дробиться на более мелкие и т.д. Этот недостаток и стимулировал создание систем управления программными пакетами и поддержания целостности системы.

Усовершенствованная система управления программными пакетами APT (Advanced Packaging Tool) первоначально была разработана для управления установкой и удалением программ в дистрибутиве Debian GNU/Linux. При разработке ставилась задача заменить используемую в Debian систему выбора программных пакетов dselect на новую, обладающую большими возможностями и простым пользовательским интерфейсом, а также позволяющую производить установку, обновление и повседневные «хозяйственные» работы с установленными на машине программами без необходимости изучения тонкостей используемого в дистрибутиве менеджера программных пакетов.

Эти привлекательные возможности были долгое время доступны только пользователям Debian GNU/Linux, поскольку в APT поддерживался только один менеджер пакетов, а именно применяемый в Debian GNU/Linux менеджер пакетов dpkg, несовместимый с используемым в ALTLinux RPM. Эта несовместимость заключается прежде всего в различии используемых форматов данных (хотя существуют программы-конвертеры), но имеются и другие различия, обсуждение которых выходит за рамки изложения.

APT, однако, изначально проектировался, как не зависящий от конкретного метода работы с установленными в системе пакетами, и эта особенность позволила разработчикам из бразильской компании Conectiva реализовать в нём поддержку менеджера пакетов RPM. Таким образом, пользователи основанных на RPM дистрибутивов (ALTLinux входит в их число) получили возможность использовать этот мощный инструмент.

APT и в настоящее время находится в стадии разработки, а текущая версия с поддержкой RPM классифицируется как нестабильная. Это, тем не менее, не означает, что операции, выполняемые посредством APT, безусловно приведут к нестабильности системы. Более того, с помощью APT возможен строгий контроль за целостностью системы: проверка нарушенных зависимостей между установленными пакетами и исправление выявленных ошибок.

Системы управления пакетами RPM и dpkg используют концепции представления программного обеспечения в виде набора компонент — программных пакетов. Такие компоненты содержат в себе набор исполняемых программ и вспомогательных файлов, необходимых для корректной работы ПО. Часто компоненты, используемые различными программами, выделяют в отдельные пакеты и помечают, что для работы ПО, предоставляемого пакетом A, необходимо установить пакет B. В таком случае говорят, что пакет A зависит от пакета B или что между пакетами A и B существует зависимость.

Отслеживание зависимостей между такими пакетами представляет собой серьёзную задачу для любого дистрибутива — некоторые компоненты могут быть взаимозаменяемыми и при удовлетворении тех или иных требований может обнаружиться несколько пакетов, предлагающих затребованный ресурс.

Задача контроля целостности и непротиворечивости установленного в системе ПО ещё сложнее. Представим, что некие программы A и B требуют наличия в системе компоненты C версии 1.0. Обновление версии пакета A, требующее обновления компоненты C до новой, использующей новый интерфейс доступа, версии (скажем, до версии 2.0), влечёт за собой обязательное обновление и программы B.

Для автоматизации этого процесса и применяется APT. Такая автоматизация достигается созданием одного или нескольких внешних репозиториев, в которых хранятся пакеты программ и относительно которых производится сверка пакетов, установленных в системе. Репозитории могут содержать как официальную версию дистрибутива, обновляемую его разработчиками по мере выхода новых версий программ, так и локальные наработки, например, пакеты, разработанные внутри компании.

Таким образом, в распоряжении APT находятся две базы данных: одна, описывающая установленные в системе пакеты, и вторая, с описанием внешнего репозитория. APT отслеживает целостность установленной системы и, в случае обнаружения противоречий в зависимостях пакетов, руководствуется сведениями о внешнем репозитории для разрешения конфликтов и поиска корректного пути их устранения.