CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
26.06.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Приложения :: Управление пакетами

Управление пакетами в BSD-системах

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

Во всех ОС BSD-клана представлены инструменты обеих групп: набор средств для манипуляции готовыми бинарниками и портообразные системы - собственно порты, используемые во FreeBSD, OpenBSD и DragonFlyBSD, и pkgsrc, разработанные в NetBSD и адаптированные для прочих представителей берклианского семейства (и не только для них).

В настоящей заметке речь пойдет только об инструментах для управления бинарниками. Они описаны на примере DragonFlyBSD, однако точно такие же утилиты установки/удаления имеются и во FreeBSD (откуда они и были перенесены в DragonFly). Сходные, до идентичности, средства пакетного менеджмента имеются также в OpenBSD и, с некоторыми оговорками, в NetBSD.

Средства для работы с бинарными пакетами во FreeBSD/DragonFly включают в себя следующие утилиты: pkg_add, pkg_create, pkg_info, pkg_version, pkg_check, pkg_delete, pkg_sign. Назначение каждой более или менее понятно из названия.

Прежде чем переходить собственно к инструментарию, посмотрим, что же представляет собой бинарный пакет FreeBSD/DragonFly. Самый простой ответ на этот вопрос таков - простой 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 и так далее, если таковые присутствуют в пакете.

Все перечисленные компоненты определяются составом пакета и возникают при его компиляции. Однако в пакете DFBSD имеются и специфические файлы, создаваемые сборщиком пакета (майнтайнером) и содержащие данные (или, точнее, метаданные о нем). Обязательными из них являются четыре: +COMMENT, +DESC, +CONTENTS, +MTREE_DIRS.

Первый файл - это краткое (в одну строку) описание пакета. Например, для консольного аудиоплейера mpg321 оно выглядит так:

A free command-line mp3 player, compatible with mpg123

Файл +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 репозитория пакетов, например (для DragonFlyBSD и оболочки tcsh)

setenv PACKAGESITE http://gobsd.com/packages/Latest/

Теперь для установки пакета со всеми его зависимостями достаточно дать команду

$ 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, дав вполне работоспособный бинарник.

Однако для сложно устроенных пакетов этот метод - не лучший. И потому штатное средство для создания автономных бинарных пакетов в BSD-системах - автоматическая из генерация через систему портов, рассмотренную в следующей заметке или pkgsrc.




Комментарии

Александр, Fri Nov 14 20:24:54 2008:
Хорошо пишете. Я бы конечно некоторые моменты оспорил, ну да ладно.
Александр, Tue Nov 4 15:39:02 2008:
Хорошо пишеш, молодец.
зы. Статья понравилась. Самому что ли завести блог? :) Давно хочу, да как то руки не доходят.
Tony, Mon Sep 29 21:57:59 2008:
Спасибо, полезный материал. Добавил ваш блог в закладки.

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds