История переиздания | |
---|---|
Издание 0.2 | 23 May 2002 |
Рабочая версия |
Содержание
Современные системы на базе 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 отслеживает целостность установленной системы и, в случае обнаружения противоречий в зависимостях пакетов, руководствуется сведениями о внешнем репозитории для разрешения конфликтов и поиска корректного пути их устранения.