Citkit, 27 июня 2005 г
Система управления пакетами - один из существенных компонентов любой операционки. Она включает средства установки, учета, обновления и удаления программного обеспечения, не обязательно входящего в базовую поставку собственно ОС. Традиционно такие системы разделяются на две группы - для работы с прекомпилированными пакетами и для сборки бинарных пакетов из исходных текстов. Впрочем, с течением времени граница между ними все более стирается.
Во всех ОС BSD-клана представлены инструменты обеих групп: набор средств для манипуляции готовыми бинарниками и портообразные системы - собственно порты (ports
), используемые во FreeBSD, OpenBSD и, до недавнего времени, в DragonFlyBSD, и pkgsrc
, разработанные в NetBSD и адаптированные для прочих представителей берклианского семейства (и не только для них).
В настоящей заметке речь пойдет только об инструментах для управления бинарниками. Они описаны на примере FreeBSD, однако сходные средства пакетного менеджмента имеются также в OpenBSD и, с некоторыми оговорками, в NetBSD и DragonFlyBSD.
Средства для работы с бинарными пакетами во FreeBSD включают в себя следующие утилиты: pkg_add
, pkg_create
, pkg_info
, pkg_version
, pkg_check
, pkg_delete
, pkg_sign
. Назначение каждой более или менее понятно из названия.
Прежде чем переходить собственно к инструментарию, посмотрим, что же представляет собой бинарный пакет FreeBSD. Самый простой ответ на этот вопрос таков - простой tar-архив, сжатый утилитой gzip
(DragonFly и FreeBSD 4-й ветки) или bzip2
(FreeBSD 5-й ветки), то есть тарбалл вида pkg_name-pkg_version.tgz
(pkg_name-pkg_version.tbz
), который можно просмотреть обычной командой вроде
$ tar tzvf pkg_name-pkg_version.tgz
или
$ tar tjvf pkg_name-pkg_version.tbz
соответственно.
Процедура эта показывает, что в состав пакета входят, как правило, следующие компоненты:
- скомпилированный и слинкованный (обычно динамически) исполняемый файл (или файлы), помещенный в каталог
bin
или, для программ системного назначения,sbin
(относительно корня архива); - необходимые конфигурационные файлы (каталог
etc
); - документацию в виде man-страницы или серии man-страниц (один из каталогов
man/man#
); - разного рода разделяемые файлы (подкаталоги каталога
share
), в частности - документацию в отличных от man-страниц форматах, если таковая предусмотрена разработчиком пакета (но не сборщиком - в BSD-системах обязательными являются только man-pages); - всякого рода библиотечные и заголовочные файлы (каталоги
lib
,include
и так далее, если таковые присутствуют в пакете.
Все перечисленные компоненты определяются составом пакета и возникают при его компиляции. Однако в пакете FreeBSD имеются и специфические файлы, создаваемые сборщиком пакета (майнтайнером) и содержащие данные о нем (или, точнее, метаданные). Обязательными из них являются четыре: +COMMENT
, +DESC
, +CONTENTS
, +MTREE_DIRS
.
Первый файл - это краткое (в одну строку) описание пакета. Например, для консольного аудиоплейера mpg321
оно выглядит так:
Файл +DESC
- это более развернутая характеристика пакета в свободной форме (обычно 1-2 абзаца). Кроме того, здесь же обычно можно видеть URL сайта его разработчика, имя майнтайнера пакета и его e-mail.
Файл +CONTENTS
можно считать главным из всего набора. В нем указаны (продолжим рассмотрение на примере mpg321
):
- имя пакета, номер его версии и ревизии (в нашем примере -
@name mpg321-0.2.10_4
); - принадлежность группе пакетов (
@comment ORIGIN:audio/mpg321
; - корневой каталог, в который будут инсталлированы компоненты пакета (почти всегда, насколько я знаю,
/usr/local
, и лишь для пакетов XFree86/Xorg -/usr/X11/R6
.
Далее следует перечисление пакетов, от которых зависит рассматриваемый (если таковые имеются). В нашем случае это будут pkgconfig
, libmad
, libid3tag
, libao
и групп, к которым они принадлежат (devel/
для pkgconfig
, audio
для остальных).
И наконец, имена файлов - компонентов пакета, с указанием путей к ним относительно корневого каталога для установки (/usr/local
и контрольных сумм каждого файла.
Файл +MTREE_DIRS
предназначен для описания структуры каталогов, указания их принадлежности и прав доступа.
А теперь начнем знакомство с инструментами управления пакетами - теми, которые окажутся наиболее востребованными. Перво-наперво о пакете нужно получить информацию. Для этого служит команда pkg_info
, использование которой несколько различается в зависимости от того, имеем ли мы дело с пакетом, уже инсталлированным в систему или только предполагаемым к установке. В первом случае достаточно дать команду с именем пакета, номером версии и ревизии в качестве аргумента:
$ pkg_info mpg321-0.2.10_4
ответом на что будет вывод содержимого файлов +COMMENT
и +DESC
:
Comment:
A free command-line mp3 player, compatible with mpg123
Description:
mpg321 is a clone of the popular mpg123 command-line mp3 player
...
и так далее. Имя пакета берется из базы данных установленного софта, которая расположена в каталоге /var/db/pkg/
(и о которой я скажу чуть ниже). Для пакета же еще не установленного (и, соответственно, в базе данных не представленного) в аргументе команды pkg_info
придется указать полное имя тарбалла и, при необходимости, полный путь к нему:
$ pkg_info /pathname/tiff-3.6.1_1.tgz
с тем же, впрочем, результатом.
Информационным целям служит и команда pkg_version
. Впрочем, она требует наличия индексного файла.
Получив представление о назначении пакета, можно переходить к его установке. Делается это с помощью команды pkg_add
, в качестве аргумента которой указывается имя нужного тарбалла, например:
$ pkg_add /pathname/zip-2.3_1.tgz
По этой команде тарбалл разворачивается, и компоненты пакета записываются в каталоги, предусмотренные в файле +CONTENTS
. Кроме того, в вышеупомянутой базе данных появляется соответствующий подкаталог (в данном случае /var/db/pkg/zip-2.3_1
, в который помещаются описанные выше файлы с данными о пакете:
$ ls /var/db/pkg/zip-2.3_1
+COMMENT +CONTENTS +DESC +MTREE_DIRS
При таком методе установки пакетов зависимости их проверяются (в соответствии с описанием в файле +CONTENTS
), но в общем случае автоматически не удовлетворяются: просто выдается сообщение, что для установки данного пакета требуется установить еще то-то и то-то. Впрочем, команда pkg_add
допускает сколько угодно аргументов, и все зависимости можно задать в одной командной строке. Можно также сложить все необходимые пакеты в один каталог - в этом случае зависимые пакеты будут установлены автоматически. В базе данных пакетов, установленных для удовлетворения зависимостей, появляется дополнительный файл - +REQUIRED_BY
, в котором перечислены пакеты (из числа установленных), для которых он необходим. Так, для мультимедийных библиотек давешнего примера содержимое его будет
mpg321-0.2.10_4
Описанный пример относится к установке пакета из произвольного каталога на локальной машине. Если же имеется подключение к сети, ситуация с зависимостями разрешается гораздо проще: в профильном файле пользователя, выполняющего установку пакета (несложно догадаться, что им будет root) достаточно определить переменную PACKAGESITE
, значением которой будет URL репозитория пакетов:
setenv PACKAGESITE [URL]
Теперь для установки пакета со всеми его зависимостями достаточно дать команду
$ pkg_add -r pkg_name
причем не нужно указывать не только путь, но и номер версии/ревизии.
Команда pkg_add
имеет ряд других опций, нужных в некоторых особых случаях. С ними можно ознакомиться в соответствующей man-странице.
Не зная броду, то есть метода удаления пакета, не лезут в воду, сиречь его инсталляцию. И потому следующим номером нашей программы будет команда pkg_delete
, роль этого брода выполняющая. В качестве аргумента она принимает имена пакетов, полежащих деинсталляции:
$ pkg_delete zip-2.3_1
Она удаляет все компоненты пакета и соответствующую запись из базы данных в каталоге /var/db/pkg/
. Однако не затрагивает пользовательских конфигов из каталога $HOME
, если они успели образоваться - ведь в базе пакетов они не фигурируют.
Попытка деинсталляции пакета, от которого зависит что-либо установленное, вызывает сообщение о невозможности это сделать, и почему - выводя имя зависимостого пакета. Конечно, деинсталляцию можно выполнить принудительно (для этого предназначена опция -f
, но это занятие нездоровое: очевидно. что зависимый пакет утратит работоспособность.
Откуда берутся пакеты, подлежащие установке и удалению? Во-первых, с дистрибутивных дисков, и во-вторых, из репозиториев на сайтах проектов. Однако никто не мешает пользователю BSD-системы собирать собственные пакеты - специально для этого предназначена утилита pkg_create
. Что для этого нужно? Не так уж и много: исходные тексты нужной версии нужной программы и те самые четыре файла с данными о пакете.
Где взять исходники - понятно, и останавливаться на этом не будем. А вот файлы с описаниями пакета придется изготовить самостоятельно. Для файлов +COMMENT
и +DESC
это труда не составит, структура файла +MTREE_DIRS
подробно описана в /usr/src/etc/mtree/README
, ну а составление файла +CONTENTS
требует знания зависимостей создаваемого пакета. Если в одном из помянутых репозиториев имеется одноименный пакет более старой версии - за образец можно взять файлы описаний из него.
Рассмотрим эту процедуру на примере текстового редактора joe
. Порядок действий таков: 1) переход к какой-либо временный подкаталог, 2) развертывание в нем тарбалла исходников joe
, 3) копирование в корень поготовленных файлов +COMMENT
, +DESC
, +MTREE_DIRS
и +CONTENTS
, 4) запуск команды pkg_create
в следующей форме:
$ pkg_create -c +COMMENT -d +DESC -f +CONTENTS -m +MTREE_DIRS joe-3.1,1
где смысл опций понятен без комментариев, а joe-3.1,1
представляет собой имя собираемого пакета. В результате получается тарбалл joe-3.1,1.tgz
, который может быть благополучно установлен командой pkg_add
, дав вполне работоспособный бинарник.
Однако для сложно устроенных пакетов этот метод - не лучший. И потому штатное средство для создания автономных бинарных пакетов во FreeBSD - автоматическая из генерация через систему портов.