архив
Zenwalk
Приобщение к Linux
2008-06-25
Глава 8. Пакеты: средства установки, системы управления, системы построения
Мысль включить эту главу появилась, с одной стороны, под влиянием обсуждения на этих страницах — спасибо некоему анониму и Олегу ОФТу за то, что привлекли внимание к этой теме. Изложенный в ней материал далеко выходит за рамки данного дистрибутива, и, казалось бы, место ему в интермедии. Однако она служит необходимым введением для главы 9 про способы манипулирования пакетами в Zenwalk, и потому должна ей предшествовать. В чем-то материал этой главы перекликается с ранее опубликованной заметкой Системы пакетного менеджмента: введение. Однако с той поры (июнь 2005 года) прошло немало времени. А как говаривали древнеримские греки, времена меняются, и мы меняемся с ними. А вместе с нами меняется и отношение к ранее написанному...
В рамках настоящей темы будут рассмотрены пакеты и способы обращения с ними. Однако для начала следует определиться, что же это такое —
Пакеты
Пакеты — это своего рода программные кванты, на которые делится система или дистрибутив. Это могут быть и простые монофункциональные утилиты (например, строчный текстовый редактор ed или архиватор tar), более или менее обширные наборы функционально связанных программ (скажем, coreutils) или составные части огромных программных комплексов (примером чему - пакеты, составляющие Xorg или KDE).
Термин пакет (английское package) постоянно употребляется в двух смыслах: как набор исходных текстов и как комплект скомпилированных из него исполняемых программ и всех их служебных файлов. В соответствии с этим следует различать пакеты авторские (пакеты исходников, или просто исходники, в просторечии именуемые сырцами — от английского Source), и пакеты дистрибутивные (они же прекомпилированные, бинарные или просто бинарники), собираемые разработчиками систем или майнтайнерами дистрибутивов.
Авторские пакеты принято распространять в виде компрессированных архивов - файлов вида *.tar.gz (*.tgz) или *.tar.bz2 (*.tbz2, *.tbz), так называемых тарбаллов. Это архивы исходных текстов, собранные в один файл утилитой tar и компрессированные с помощью программ сжатия gzip или bzip2, соответственно. Обычно для авторских пакетов действует правило: один тарбалл - один пакет. Очень большие пакеты могут быть поделены на несколько тарбаллов (например, Xorg), но делается это исключительно для удобства скачивания, все равно такой набор тарбаллов исходников сохраняет свою целостность.
Однозначной корреляции между авторскими и дистрибутивными пакетами нет. В одних случаях бинарный пакет представляет собой просто откомпилированный пакет авторский. В других же — авторский пакет делится на ряд монофункциональных бинарных пакетов. Возможно и объединение дистрибутивных пакетов, функционально связанных между собой, в единый комплекс, именуемый метапакетом. Который, впрочем, представляет собой просто определенным образом организованный список входящих в его состав обычных дистрибутивных пакетов.
И для авторских, и для дистрибутивных пакетов очень важно понятие зависимостей. Зависимости — это пакеты, которые требуются для функционирования пакета устанавливаемого. Как правило, они представляют собой некие библиотеки функций. Различают зависимости «жесткие», или обязательные, и «мягкие», или дополнительные. Без удовлетворения первых пакет просто не будет работать. «Мягкие» зависимости обеспечивают пакету некую дополнительную функциональность, желательную с точки зрения майнтайнера пакета (но не обязательно — с точки зрения пользователя).
Для дистрибутивных пакетов существует несколько видов распространения или, как принято говорить, форматов пакетов. Самый простой из таких форматов — те же тарбаллы, включающие в себя, однако, не исходные тексты, а уже скомпилированные исполняемые файлы, обеспечивающие их работу библиотеки, сопутствующую документацию, и так далее. Установка такого тарбалла сводится к его развертыванию и инкорпорации в дерево файловой иерархии целевой системы. Кроме того, бинарный тарбалл может включать (и, как правило, включает) сценарии, выполняемые до и после установки пакета.
Классический пример «чистых» бинарных тарбаллов — пакеты Slackware и производных от него дистрибутивов, не содержащие никакой метаинформации, то есть сведений о зависимостях пакетов. Такой пакет с помощью соответствующих средств будет установлен в любом случае, но без разрешения зависимостей работать не будет. А разрешение это отдается на откуп пользователю.
Однако нередко тарбаллы могут включать в себя и метаинформацию о зависимостях. Она будет использована средствами установки пакетов для отказа от установки пакета и вывода сообщения об ошибках при нарушении зависимостей, или системами управления пакетами — для автоматического разрешения зависимостей.
Важно отметить, что отсутствие в составе пакета информации о его зависимостях отнюдь не препятствует контролю над ними: он может осуществляться за счет внешних баз данных репозиториев пакетов и локальных баз данных пакетов установленных. А функции удовлетворения зависимостей в этом случае целиком ложатся на программы, осуществляющие пакетный менеджмент. И надо отметить, что управление «чистыми» тарбаллами подчас оказывается более гибким, чем пакетами с информацией об их зависимостях.
Впрочем, с этим я несколько забежал вперед — вернемся к форматам распространения пакетов.
Два других широко распространённых формата пакетов — rpm (Red Hat Packages Manager, характерный для одноименного дистрибутива и его многочисленных потомков) и deb (свойственный дистрибутиву Debian и его ещё более многочисленным клонам). И тот, и другой, в конечном счете, также представляют собой компрессированные архивы бинарных файлов с указанием путей, которые они должны занять в файловой иерархии. Однако помимо этого, они содержат дополнительную информацию, в том числе и о зависимостях, хотя и представленную в разной форме.
В rpm-пакетах эта информация содержится внутри пакета в файле REQUIRENAME, который можно просмотреть, например, с помощью функции просмотра программы Midnight Commander (при наличии в системе установленной программы rpm, которую можно найти в большинстве дистрибутивов). Этот просто список библиотечных файлов, требующихся для работы данного пакета, без указания, к какому пакету они сами принадлежат. Это можно видеть на рис. 8.01 на примере пакета для текстового редактора joe.
Рис. 8.01. Список зависимостей rpm-пакета редактора joe
Кроме того, на том же рисунке можно видеть, что в этом списке никак не разделяются «жесткие» (в данном случае, например, libc.so.6 и libmcurses.so.5) и «мягкие» (в частности, libselinux.so.1) зависимости. И то, и другое, как мы увидим со временем, создает изрядные неудобства при использовании средств установки rpm-пакетов.
Еще один недостаток rpm-пакетов — то, что время от времени разработчики его меняют сам их формат. Насколько я помню, такая смена формата произошла при переходе от 3-й его версии к 4-й, ныне текущей, и принятой во всех базирующихся на rpm дистрибутивах. Однако в настоящее время разрабатывается 5-я версия, которую, при всех её усовершенствованиях, обещают сделать абсолютно несовместимой с версией 4-й. Кроме того, устройство rpm-пакетов несколько различается даже в дистрибутивах, использующих одну и ту же версию этого формата.
Этих недостатков лишен deb-формат пакетов. Будучи исторически чуть ли не первым «не чистым тарбаллом», он сохраняет своё внутреннее устройство неизменным на протяжении уже полутора десятков лет. И при этом оно абсолютно одинаково во всех дистрибутивах, производных от Debian: пакет из Ubuntu обычно может быть установлен в материнской системе, и наоборот. Возможны, конечно, нестыковки, но они связаны не с форматом пакетов, а исключительно с версиями библиотек, от которых они зависят — в разных дистрибутивах они могут несколько различаться.
deb-пакет представляет собой ar-архив (ar — архиватор, подобный tar), включающий три файла: data.tar.gz — собственно откомпилированные бинарники пакета, control.tar.gz — собрание всякого рода служебной информации, в том числе и о зависимостях.
Информация о зависимостях, в числе прочей метаинформации, содержится в файле control одноименного архива. Из рисунка 8.02 (deb-пакет для Midnight Commander) можно видеть, что, во-первых, в списке зависимостей фигурируют названия пакетов, а не имена файлов. Во-вторых, четко различаются «жесткие» и «мягкие» зависимости. Причем среди последних существует две градации: рекомендуемые (recommends) и предлагаемые (suggests), первая из которых является более важной (с точки зрения майнтайнера пакета), но столь же необязательной для всех остальных, как и вторая.
Рис. 8.02. Список зависимостей rpm-пакета редактора joe
Кроме зависимостей, для deb-пакетов важно также понятие приоритета пакета, отражающее степень необходимости его для функционирования системы, например: обязательный (required), без которого функционирование системы невозможно, основной (base) и важный (important), также оказывающиеся практически необходимыми, стандартный (standard) - то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный (optional) - тут уж степень важности каждый должен решать для себя.
Изначальная продуманность и неизменность формата deb-пакетов послужила причиной того, что он лег в основу развитых систем пакетного менеджмента, о чем мы поговорим в своё время.
Стоит заметить, что существуют средства взаимной трансформации пакетов разных форматов, по крайней мере наиболее распространенных — тарбаллов различных видов, rpm, deb. Это простые утилиты типа rpm2cpio или rpm2tgz, а также почти универсальная программа alien. Однако возможности их применения ограничены - очевидно, что из rpm-пакета (и тем более «чистого» тарбалла) получить полноценный deb-пакет невозможно. Поэтому наиболее успешно такие программы работают в направлении «от сложного к простому». Правда, при установке продуктов такой трансформации следует учитывать различия в файловой иерархии дистрибутивов и, возможно, в версиях зависимостей.
Кроме форматов rpm и deb, существуют и другие бинарные форматы, но они, как правило, не получили распространения за пределами того дистрибутива или системы, для которых были созданы. Так что речи о них здесь не будет, тем более что на очереди у нас следующий вопрос —
Обращение с пакетами
Пакеты собираются для того, чтобы быть «разобранными» — то есть разбитыми на составляющие их файлы, включаемые в файловую иерархию системы. И то и другое обеспечивается средствами установки пакетов, системами управления пакетами (системами пакетного менеджмента) и системами построения пакетов (в просторечии портами).
Под средствами установки пакетов будут пониматься утилиты, предназначенные для установки, обновления и удаления единичных пакетов, а также получения информации о них.
Системы пакетного менеджмента, выполняя все функции установщиков, кроме того, обеспечивают автоматический контроль зависимостей как на стадии инсталляции, так и при удалении программ, позволяя произвести «чистую» деинсталляцию.
Системы построения пакетов по своим задачам и функциям аналогичны системам управления пакетами, но оперируют не прекомпилированными пакетами, а исходными текстами, из которых по определенным правилам собираются пакеты, пригодные для установки и использования.
Резкой границы между средствами установки, системами управления пакетами и системами построения пакетов нет: нередко одна и та же утилита установки пакета, вызванная с различными параметрами, может как осуществить установку или удаление единичного пакета, так и выполнить полное «разруливание» его зависимостей, и со временем мы рассмотрим примеры таких утилит.
Тем не менее, средства установки пакетов и системы пакетного менеджмента — это несколько разные понятия.
Различие между ними проявляются, в частности, в том, что первые жестко привязаны к формату пакетов. Так, утилита rpm обеспечивает установку одноименных пакетов, семейство утилит dpkg предназначено для обращения с deb-пакетами, и так далее.
Подчас такие утилиты носят одинаковые или похожие имена. Например, команду pkg_add, осуществляющую установку тарбаллов, можно видеть в Slackware и её клонах и во всех системах BSD-семейства. Однако всё это — разные утилиты, и с помощью pkg_add из Slackware так же нельзя установить пакет из FreeBSD, как и выполнить обратную процедуру. Даже pkg_add из близкородственных FreeBSD и NetBSD (и DragonFlyBSD) не являются одинаковыми. Когда в DragonFleBSD некоторое время сосуществовали система портов, унаследованная из FreeBSD, и pkgsrc, заимствованная из NetBSD, для установки пакетов, сгенерированной той или другой из них, приходилось держать pkg_add, pkg_del и тому подобные утилиты в двух вариантах — из FreeBSD и из NetBSD.
Системы пакетного менеджмента зародились как дистрибутив-специфичные надстройки над средствами установки пакетов, и потому первоначально тоже были привязаны к их формату, а также совершенно определенному дистрибутиву или даже операционной системе.
Однако довольно быстро оказалось, что одна и та же система управления пакетами, с некоторыми оговорками, может быть использована для работы с пакетами совершенно различных форматов. Так, механизм apt-get, разработанный как надстройка над утилитами dpkg из дистрибутива Debian, был приспособлен для работы с пакетами rpm-формата в рамках дистрибутива Connectiva (ныне - составляющая часть компании Mandriva), а затем и для чистых тарбаллов Slackware.
С другой стороны, инфраструктура Debian, базирующаяся на его формате пакетов и системе управления оными, нашла свое место и как надстройка над ядрами совершенно других операционных систем, например, FreeBSD (проект Debian GNU/kFreeBSD ) и OpenSolaris (проект Nextenta).
Даже такой менеджер пакетов, как pacman от Archlinux, привязанный к далеко не самому распространенному дистрибутиву, был перенесен на Slackware, в результате чего появился дистрибутив с труднопроизносимым названием Frugalware.
Системы построения пакетов, очевидно, не привязаны ни к какому формату оных, так как основываются на авторских исходниках. Сказанное же выше о кросс-платформенности пакетного менеджмента применимо и к ним, пожалуй, даже в большей степени.
Порты FreeBSD не только послужили прототипом всех остальных систем построения пакетов, но и в своем первозданном виде были заимствованы OpenBSD, а также неоднократно «прикручивались« к различным дистрибутивам Linux, в первую очередь — к Slackware. С другой стороны, уже давно существует и время от времени реанимируется проект обратного портирования портежей.
Система pkgsrc, изначально разработанная для NetBSD, практически сразу также стала кросс-платформенной, и ныне список поддерживаемых ею операционок насчитывает чёртову дюжину позиций. в их числе — BSD-системы (кроме NetBSD — также DragonFlyBSD, в которой она стала единственным средством пакетного менеджмента, OpenBSD, где она конкурирует с портами из FreeBSD, и, если Darwin тоже считать BSD-отростком, то MacOS X), Linux (ряд клонов Slackware обрёл в pkgsrc недостающую родительнице систему управления пакетами), практически все ныне живущие коммерческие UNIX'ы и даже QNX.
Иными словами, кросс-платформенность и мультиформатность нынче скорее правило, чем исключение для систем управления пакетами и систем построения оных. Остались не охваченными этим движением только пакетные менеджеры — выходцы из среды rpm-based дистрибутивов, такие, как yum и urpmi. Вероятно, потому что на других платформах с более иными форматами они оказались просто не востребованы.
Так что дела о средствах установки пакетов, системах пакетного менеджмента и системах построения пакетов целесообразно выделить в отдельные производства. Первыми,как более простые, будут рассмотрены...