Средства управления пакетами
Вопросу ручной сборки программ выше было уделено чень много места. Однако на самом деле пользователю не так уж и часто приходится заниматься этим делом. Потому что любая уважающая себя система, как было сказано в главе 2, обладает тем или иным способом автоматизации установки и удаления программ, избавляющей не только от отслеживания зависимостей, но обычно даже и от компиляции, то есть системой управления пакетами.
Средства управления пакетами чрезвычайно разнообразны. В первом приближении их можно разделить на два класса - системы портов и собственно системы пакетного менеджмента.
Системы портов пришли из мира BSD, где впервые появились во FreeBSD. Собственно, порты - это родовое имя системы пакетного менеджмента этой операционки. Все остальные портообразные системы возникли и развивались под сильным ее влиянием. Наибольшее распространение и известность получили pkgsrc и портежи (portages).
Первая система возникла первоначально в NetBSD, постепенно превратившись в кроссс-платформенное средство управления пакетами: существуют ее версии для всех BSD-систем (включая DragonFly), ряда дистрибутивов Linux и даже для таких проприетарных Unix'ов, как Solaris и IRIX.
Система портежей была разработана для дистрибутива Gentoo Linux. Однако и она быстро обрела черты кросс-платформенности: более или менее активно разрабатываются ее варианты для FreeBSD и NetBSD, поговаривают о переносе ее на Hurd и другие дистрибутивы Linux.
Тем не менее, практически каждый дистрибутив Linux, относимый к классу Source Based, обладает собственной, более или менее оригинальной, портообразной системой (почему я и полагаю, что их следует называть скорее портируемыми дистрибутивами). Тут следует упомянуть и ABS - Archlinux Building System из одноименного дистрибутива, и порты CRUX, и Sorcery из Sorcerer Linux и его потомков (Source Mage и Linar). И примеры портообразных систем множатся с каждым днем: только за истекший год появились дистрибутивы Rubyx и MyGeOS - каждый со своей портообразной системой.
Не смотря на такое разнообразие конкретных реализаций, общие черты любой портообразной системы вычленить очень легко: это набор правил для отыскания в Сети исходников устанавливаемых программ, их получения на локальную машину, развертывания тарбаллов, конфигурирования, сборки (компиляции и линковки), инсталляции в файловую систему и, возможно, постинсталляционного конфигурирования. То есть по этим правилам выполняется весь тот цикл действий, которые мы проделываем при ручной сборке любой программы (вспомним три волшебных заклинания ./configure, make, make install из предшествующих параграфов), но - в автоматическом режиме. Однако в добавок к этому система портов включает такойму важный для управления пакетами компонент, как средства выявления и отслеживания зависимостей, как "жестких", обязательных, так и "мягких", опциональных, коррекции последних в ту или иную сторону, ну и, конечно же, автоматического удовлетворения тех и других.
Собственно системы пакетного менеджмента - это инструменты для установки и удаления ранее скопмилированных бинарных пакетов. Что такое бинарный пакет - легко представить себе, если вернуться к процессу сборки программ, описанному выше. Как мы помним, собственно стадия сборки (исполнение процедуры make) завершается тем, что полностью собранные, готовые к употреблению, компоненты пакета располагаются в промежуточном каталоге.
По умолчанию каталог для промежуточных продуктов сборки - то же самый, что и для исходных текстов. Однако, если на стадии конфигурирования задать какой-либо иной адрес сборки, например
$ ./configure --prefix=/path_to/pkgname
то бинарные компоненты пакета будут собраны в отдельном каталоге с подкаталогами pkgname/bin, pkgname/lib, pkgname/share и так далее. И если этот каталог заархивировать утилитой tar и сжать посредством gzip или bzip2 - то получится автономный бинарный пакет в простейшей своей форме - в виде простого тарбалла. Для использования остается только развернуть его и инкорпорировать в древо файловой системы.
Эту задачу и выполняют система пакетного менеджмента, обеспечивая заодно и контроль зависимостей при установке.
По формату пакеты в первом приближении можно разделить на две группы - те, что содержат внутри себя метаинформацию (в частности, информацию о зависимостях пакетов), и таковой лишенные.
К первой группе относятся широко распространенные форматы пакетов rpm (Red Hat Packages Manager, характерный для одноименного дистрибутива и его многочисленных потомков) и deb (свойственный дистрибутиву Debian и на нем основанным). И тот, и другой, помимо собственно архива бинарных файлов и путей к ним, содержат данные о зависимостях, хотя и представленные в разной форме.
Пакеты без метаданных - это обычные тарбаллы, то есть компрессированные tar-архивы типа *tar.gz/*tar.bz2 (часто фигурирующие в форме tgz и tbz). Важно, что сами по себе tgz,tbz и им подобные - это форматы вовсе не пакета, а именно архива (то есть определяются используемой утилитой компрессии - gzip или bzip2, соответственно). А важно это потому, что те же самые tgz/tbz архивы могут прекрасно содержать в себе и метаинформацию, оказываясь более сходными с пакетами rpm или deb (и ниже мы столнемся с примерами этого). Характерным примером чего являются packages BSD-систем, включающих в себя полное описание зависимостей.
Еще более существенно то, что отсутствие в составе пакета информации о его зависимостях отнюдь не препятствует контролю над ними: он может осуществляться за счет внешних баз данных репозиториев пакетов и локальных баз данных пакетов установленных. А функции удовлетворения зависимостей в этом случае целиком ложатся на программы, осуществляющие пакетный менеджмент. И надо отметить, что управление "чистыми" тарбаллами подчас оказывается более гибким, чем пакетами с информацией об их заивисимостях.
Средства пакетного менеджмента жестко привязаны к формату пакетов - для установки rpm-пакетов служит одноименная утилита (rpm), пакеты deb устанавливаются посредством утилиты dpkg, для пакетных тарбаллов предусмотрены собственные средства, обычно - дистрибутив-специфичные, не смотря на похожие, и даже подчас одинаковые, имена.
Конечно, существуют средства взаимной трансформации пакетов разных форматов (типа rpm2cpio, rpm2tgz или почти универсальной утилиты alien), однако возможности их применения ограничены - очевидно, что из rpm-пакета (и тем более "чистого" трабалла) получить полноценный deb-пакет невозможно.
Однако существуют еще и средства пакетного мета-менеджмента, если так можно выразиться (собственно, только они-то и заслуживают названия систем управления пакетами). Наиболее известное и распространенное из них - apt. Появившийся сначала в Debian'е и рассчитанный, соответственно, на deb-пакеты, он очень быстро стал универсальным кросс-пакетным механизмом установки, удаления и обновления программ, успешно работая с пакетами rpm (дистрибутивы Connectiva, Altlinux), тарбаллами Slackaware (механизм slapt-get). И в принципе не видно препятствий к прикручиванияю его к тарбаллам любого формата - от "чистых" до сколь угодно насыщенных метаинформацией.
Под явным влиянием apt возникли и иные системы пакетного менеджмента - yum, urpmi и так далее. Однако они ориентированы только на rpm-пакеты (вероятно, их можно использовать и для иных форматов, но кому это нужно при наличии apt?) и потому не получили столь широкого распространения, оставаясь принадлежностью "родительских" дистрибутивов и более-менее точных их клонов (yum, насколько мне известно, используется только в Red Hat/Fedora и ASPlinux).
Следует помнить, что резкую границу между системами портов и средствами пакетного менеджмента провести нелегко. Все портообразные системы позволяют выполнить сборку автономных бинарных пакетов и, соответственно, включают средства их установки, регистрации и удаления. А в системах пакетного менеджмента можно обнаружить инструментарий для автоматической компиляции программ из исходников, хотя они и играют сугубо вспомогательную роль.
