Для дистрибутивных пакетов существует несколько видов распространения или, как принято говорить, форматов пакетов. Одни из них (rpm или deb) получили широкое распространение за пределами материнских систем, другие используются только в “родных” дистрибутивах, третьи же достаточно объединяются в группы достаточно условно.
Самый простой из таких форматов — те же тарбаллы, включающие в себя, однако, не исходные тексты, а уже скомпилированные исполняемые файлы, обеспечивающие их работу библиотеки, конфигурационные файлы, сопутствующую документацию, и так далее. Установка такого тарбалла сводится к его развертыванию и инкорпорации в дерево файловой иерархии целевой системы. Кроме того, бинарный тарбалл может включать (и, как правило, включает) сценарии, выполняемые до и после установки пакета.
Классический пример «чистых» бинарных тарбаллов — пакеты Slackware и производных от него дистрибутивов, не содержащие никакой метаинформации, то есть сведений о зависимостях пакетов. Такой пакет с помощью соответствующих средств будет установлен в любом случае, но без разрешения зависимостей работать не будет. А разрешение это отдаётся на откуп пользователю.
Однако нередко тарбаллы могут включать в себя и метаинформацию о зависимостях. Она будет использована средствами установки пакетов для отказа от установки пакета и вывода сообщения об ошибках при нарушении зависимостей, или системами управления пакетами — для автоматического разрешения зависимостей.
Важно отметить, что отсутствие в составе пакета информации о его зависимостях отнюдь не препятствует контролю над оными: контроль этот может осуществляться за счёт внешних баз данных репозиториев пакетов и локальных баз данных пакетов установленных. А функции удовлетворения зависимостей в этом случае целиком ложатся на программы, осуществляющие пакетный менеджмент. И надо отметить, что управление «чистыми» тарбаллами подчас оказывается более гибким, чем пакетами с информацией об их зависимостях.
Впрочем, с этим я несколько забежал вперёд — вернёмся к форматам распространения пакетов.
Два других широко распространённых формата пакетов — rpm (RPM Packages Manager, характерный для одноимённого дистрибутива и его многочисленных потомков) и deb (свойственный дистрибутиву Debian и его ещё более многочисленным клонам). И тот, и другой, в конечном счёте, также представляют собой компрессированные архивы бинарных файлов с указанием путей, которые они должны занять в файловой иерархии. Однако помимо этого, они содержат дополнительную информацию, в том числе и о зависимостях, хотя и представленную в разной форме.
В rpm-пакетах эта информация содержится внутри пакета в файле REQUIRENAME, с которым можно ознакомиться, например, с помощью функции просмотра программы Midnight Commander (при наличии в системе установленной программы rpm, которую можно найти в большинстве дистрибутивов). Этот просто список библиотечных файлов, требующихся для работы данного пакета, без указания, к какому пакету они сами принадлежат. Это можно видеть на скриншоте — в качестве примера дан пакет для текстового редактора joe.
Кроме того, на том же рисунке можно видеть, что в этом списке никак не разделяются «жесткие» (в данном случае, например, libc.so.6 и libmcurses.so.5) и «мягкие» (в частности, libselinux.so.1) зависимости. И то, и другое, как мы увидим со временем, создаёт изрядные неудобства при использовании средств установки rpm-пакетов.
Еще один недостаток rpm-пакетов — то, что время от времени разработчики его меняют сам их формат. Насколько я помню, такая смена формата произошла при переходе от 3-й его версии к 4-й, ныне текущей, и принятой во всех базирующихся на rpm дистрибутивах. Однако в настоящее время разрабатывается 5-я версия, которую, при всех её усовершенствованиях, обещают сделать абсолютно несовместимой с версией 4-й. Поэтому ни один из rpm-based дистрибутивов перехода на новый формат пока не планируют. Единственное известное мне исключение — PLD Linux.
Кроме того, устройство rpm-пакетов несколько различается даже в дистрибутивах, использующих одну и ту же версию этого формата. Так что установка rpm-пакета, собранного для Suse, более чем не гарантируется в Mandriva, и наоборот. Впрочем, на все озвученные темы у нас будет повод поговорить подробнее.
Отмеченных для rpm-формата недостатков более или менее лишён deb-формат пакетов. Будучи исторически чуть ли не первым «не чистым тарбаллом», он сохраняет своё внутреннее устройство неизменным на протяжении уже полутора десятков лет. И при этом оно абсолютно одинаково во всех дистрибутивах, производных от Debian: пакет из Ubuntu обычно может быть установлен в материнской системе, и наоборот. Возможны, конечно, нестыковки, но они связаны не с форматом пакетов, а исключительно с версиями библиотек, от которых они зависят — в разных дистрибутивах они могут несколько различаться.
Пакет deb-формата представляет собой ar-архив (ar — архиватор, подобный tar, но более древний), включающий три файла: data.tar.gz — собственно откомпилированные бинарники пакета, control.tar.gz — собрание всякого рода служебной информации, в том числе и о зависимостях.
Информация о зависимостях, в числе прочей метаинформации, содержится в файле control одноимённого архива. Из скриншота (deb-пакет для Midnight Commander) можно видеть, что, во-первых, в списке зависимостей фигурируют названия пакетов, а не имена файлов. Во-вторых, четко различаются «жесткие» и «мягкие» зависимости. Причём среди последних существует две градации: рекомендуемые (recommends) и предлагаемые (suggests), первая из которых является более важной (с точки зрения майнтайнера пакета), но столь же необязательной для всех остальных, как и вторая.
Кроме зависимостей, для deb-пакетов важно также понятие приоритета пакета, отражающее степень необходимости его для функционирования системы, например: обязательный (required), без которого функционирование системы невозможно, основной (base) и важный (important), также оказывающиеся практически необходимыми, стандартный (standard) — то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный (optional) — тут уж степень важности каждый должен решать для себя.
Изначальная продуманность и неизменность формата deb-пакетов послужила причиной того, что он лёг в основу ряда развитых систем пакетного менеджмента, о чем мы поговорим в своё время.
Стоит заметить, что существуют средства взаимной трансформации пакетов разных форматов, по крайней мере наиболее распространённых — тарбаллов различных видов, rpm, deb. Это простые утилиты типа rpm2cpio или rpm2tgz, а также почти универсальная программа alien. Однако возможности их применения ограничены — очевидно, что из rpm-пакета (и тем более «чистого» тарбалла) получить полноценный deb-пакет невозможно. Поэтому наиболее успешно такие программы работают в направлении «от сложного к простому». Правда, при установке продуктов такой трансформации следует учитывать различия в файловой иерархии дистрибутивов и, возможно, в версиях зависимостей.
Кроме форматов rpm и deb, существуют и другие бинарные форматы, но они, как правило, не получили распространения за пределами того дистрибутива или системы, для которых были созданы. Так что речи о них здесь не будет, тем более что на очереди у нас следующий вопрос — о способах обращения с пакетами.
- Пакеты: введение
- Что такое пакеты
- Понятие зависимостей
- О библиотечных пакетах
- Основные библиотеки графического режима
- Форматы пакетов
- Обращение с пакетами
- Средства установки пакетов
- Пакетный менеджмент
- Системы построения пакетов
Теги: deb, rpm, tarball, системы