Системы пакетного менеджмента: введение

2005-06-27

Этот цикл посвящается средствам управления пакетами, предназначенным для установки, обновления и удаления программ, учета и разрешения их зависимостей. Средства эти обычно дистрибутив-специфичны, и потому, казалось бы, место им в разделе дистрибутивов. Однако в последнее время все большее распространение получают кросс-дистрибутивые (и даже кросс-системные) инструменты для управления пакетами. А главное, пакетный менеджмент - не самоцель, а лишь сресдство для наращивания пользовательской функциональности любой систсемы. И потому в итоге решено поместить этот цикл в раздел Приложений.

Средства управления пакетами можно разделить на две группы:

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

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

К первой группе относятся широко распространенные форматы пакетов rpm (Red Hat Packages Manager, характерный для одноименного дистрибутива и его многочисленных потомков) и deb (свойственный дистрибутиву Debian и на нем основанным). И тот, и другой, помимо собственно архива бинарных файлов и путей к ним, содержат данные о зависимостях, хотя и представленные в разной форме.

Пакеты без метаданных - это обычные тарбаллы, то есть компрессированные tar-архивы типа *tar.gz/*tar.bz2 (часто фигурирующие в форме tgz и tbz). Важно, что сами по себе tgz и tbz - это форматы вовсе не пакета, а именно архива (то есть определяются используемой утилитой компрессии - gzip или bzip2, соответственно). А важно это потому, что те же самые tgz/tbz архивы могут прекрасно содержать в себе и метаинформацию, оказываясь более сходными с пакетами rpm или deb (например, packages FreeBSD).

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

Программы пакетного менеджмента - еще один из критериев классификации. Правда, собственно средства установки пакетов жестко привязаны к их формату - для установки rpm-пакетов служит одноименная утилита ( rpm), пакеты deb устанавливаются посредством утилиты dpkg, для пакетных тарбаллов предусмотрены собственные средства, в зависимости от их формата, типа pkg_add (и обычно - дистрибутив-специфичные, не смотря на похожие, и даже подчас одинаковые, имена). Конечно, существуют средства взаимной трансформации пакетов разных форматов (типа rpm2cpio, rpm2tgz или почти универсальной утилиты alien), однако возможности их применения ограничены - очевыдно, что из rpm-пакета (и тем более "чистого" трабалла) получить полноценный deb-пакет невозможно.

Однако существуют еще и средства пакетного мета-менеджмента, если так можно выразиться (собственно, только они-то и заслуживают названия систем управления пакетами). Наиболее известное и распространенное из них - apt. Появившийся сначала в Debian'е и рассчитанный, соответственно, на deb-пакеты, он очень быстро стал универсальным кросс-пакетным механизмом установки, удаления и обновления программ, успешно работая с пакетами rpm (дистрибутивы Connectiva, Altlinux), тарбаллами Slackaware (механизм slapt-get). И в принципе не видно препятствий к прикручиванияю его к тарбаллам любого формата - от "чистых" до сколь угодно насыщенных метаинформацией.

Под явным влиянием apt возникли и иные системы пакетного менеджмента - yum, urpmi и так далее. Однако они ориентированы только на rpm-пакеты (вероятно, их можно использовать и для иных форматов, но кому это нужно при наличии apt?) и потому не получили столь широкого распространения, оставаясь принадлежностью "родительских" дистрибутивов и более-менее точных их клонов (yum, насколько мне известно, используется только в Red Hat/Fedora и ASPlinux).

Прародителем всех портообразных средств управления пакетами была система портов FreeBSD, практически в неизменном виде заимствованная OpenBSD и DragonFlyBSD. Под ее влиянием возникла система очень сходная система pkgsrc в NetBSD. Которая очень быстро вышла за рамки родительской операционки, и ныне может использоваться в любой BSD-системе (вплоть до Darwin и MacOS X), в ряде дистрибутивов Linux (Debian, Slackware) и даже в проприетарных Unix'ах (Solaris, IRIX).

Однако разработчики дистрибутивов Linux, как правило, идут своим путем в деле создания систем портирования. Правда, такие их представители, как CRUX и Archlinux, не очень далеко отошли от прототипа. В них портообразные системы (ports и ABS, соответственно) мирно сосуществуют с самостоятельными (и весьма развитыми) средствами пакетного менеджмента: так, pacman из Archlinux, если еще и не достиг мощи Debian'овского apt'а, то стремительно движется в этом направлении. Тем не менее, сами пакеты, распространяемые в состве дистрибутива, генерируются за счет портообразной системы, которая позволяет также легко выполнить и пересборку базовой системы в соответсвие с запросами пользователя.

К слову говоря, пакеты Archlinux, представляющие собой "чистые" тарбаллы, являют пример эффективного контроля зависисмостей за счет внешних баз данных - базы пакетного репозитория (на установочном диске и на сервере проекта) и базы пакетов, установленных на локальной машине. Гибкость такого "внешнего" метода пакетного менеджмента определяется тем, что пользователь может легко создать собственный пакетный репозиторий в базой данных, в которой описаны только нужные ему зависимости.

Самой известной, распространенной и, я бы сказал, самой изощренной портообразной системой Linux-мира являются портэжи (portages) из дистрибутива Gentoo, меньшей популярностью пользуются sorcery, применяемый в дистрибутивах Sorcerer и SourceMage, и его потомок lunar из одноименного дистрибутива. Не смотря на их принципиальное сходство (обусловленное наследованием идейных традиций портов FreeBSD), двух одинаковых среди них мы не обнаружим - система portage из Gentoo отличается от "заклинаний" (sorcery) из Sorcerer как реализацией, так и приемами использования.

Далее в этом цикле планируется описание всех распространенных систем управления пакетами - как бинарными, так и собираемыми из исходников.