Погружение в Salix

В восьмой главе рассказывается о сборке пакетов из исходных текстов и о специально предназначенном для этого механизме Slackbuilds, о репозиториях слакбилдов вообще и официальных репозиториях слакбилдов для Salix в частности, а также об утилите slapt-src, служащей для работы со слакбилдами.

Что такое slackbuilds

В самом общем виде слакбилд – это просто сценарий автоматической сборки любого бинарного пакета из его исходных текстов, обеспечивающий выполнение (почти) всех стадий этого процесса – получение «авторского» архива, его развёртывание в дерево исходников, их конфигурирование и собственно компиляцию, завершающуюся созданием бинарного пакета в формате Slackware. В идее слакбилдов легко увидеть черты сходства с портами FreeBSD, портежами Gentoo и особенно с Arch Building System дистрибутива Archlinux. Однако есть и несколько важных различий со всеми перечисленными системами пакетного менеджмента. О некоторых я скажу чуть позже.

Именно из слакбилдов собираются пакеты Slackware и всех её клонов, в том числе и Salix – те самые, которые лежат в соответствующих официальных репозиториях. Однако существует и огромное число пакетов, по тем или иным причинам не попавшим в состав «бинарного официоза» ни одного из дистрибутивов. Вот среди них и следует искать наши «недостачи».

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

Рисунок 8-1. Структура репозитория SlackBuilds.org

Обращение с найденным слакбилдом в общем случае примерно таково (хотя детали могут меняться). Вначале он (то есть файл вида *.SlackBuild и несколько файлов с метаинформацией, в том числе файлом README) скачивается в подходящий каталог, затем ему присваивается аттрибут исполнения:

$ chmod a+x *.SlackBuild

После чего эту способность к исполнению надлежит реализовать:

$ ./*.SlackBuild

Для обеих процедур, как можно видеть, достаточно прав обычного пользователя. В результате второй в текущем каталоге появляется скачанный из сети архив исходных текстов, файл проверки контрольной суммы, а в каталоге /tmp – готовый бинарный пакет, то есть файл вида *.txz. Который остаётся только установить обычным образом, например, описанным в главе пятой, разумеется, уже с правами администратора:

$ sudo installpkg *.txz

В самих по себе слакбилдах штатно не предусмотрено никакого механизма контроля зависимостей – кроме, разумеется, вывода сообщений в случае их нарушения. Централизованно не предлагает такого механизма и сам репозиторий SlackBuilds.org. В этом первое важное отличие слакбилдов от систем типа портов или портежей.

Однако некоторый контроль зависимостей при построении слакбилдов и не запрещается: автор может перечислить их в упомянутом только что файле README. Но делать этого он не обязан. И это вторая важная их особенность: если порты или портежи претендуют на универсальность и «всеохватность», и потому более или менее поддерживаются в целостном состоянии, то каждый слакбилд – продукт «индивидуальный». Автор его в явном или не явном виде как бы говорит, что сделал его для собственных целей, а уж дальше – не его дело. И SlackBuilds.org – это просто «копилка» таких индивидуальных решений.

Разумеется, сказанное не относится к слакбилдам, с помощью которых собираются пакеты официальной части Slackware или Salix (а это, повторяю, точно такие же слакбилды, как и любые другие): здесь майнтайнеры дистрибутивов в лице, соответственно, Патрика или Георгия с соратниками за целостностью системы следят.

Однако Salix предоставляет некоторую возможность контроля зависимостей при сборке произвольных слакбилдов – собственный официальный их репозиторий.

Слакбилбы и Salix

В официальном репозитории Salix можно увидеть целых два хранилища слакбилдов --sbo и slkbuild.

Рисунок 8-2. Корень официального репозитория Salix

Чтобы больше не возвращаться к этому вопросу – для начала скажу пару слов о ветке slkbuild. Не смотря на кажущееся изобилие разделов, повторяющих структуру SlackBuilds.org, на момент сочинения этих строк она включает в себя всего два пакета весьма специфического назначения, в чём легко убедиться, просмотрев, например, /slkbuild/14.1/SLACKBUILDS.TXT:

SLACKBUILD NAME: pastebinitSLACKBUILD LOCATION: ./misc/pastebinit SLACKBUILD FILES: SLKBUILD slack-desc pastebinit-1.3.1.tar.gz SLACKBUILD VERSION: 1.3.1 SLACKBUILD REQUIRES: python,configobj SLACKBUILD SHORT DESCRIPTION: pastebinit (pastebin from the command line) SLACKBUILD NAME: solaar SLACKBUILD LOCATION: ./system/solaar SLACKBUILD FILES: SLKBUILD slack-desc 0.9.2.tar.gz SLACKBUILD VERSION: 0.9.2 SLACKBUILD REQUIRES: dbus-python,pygobject3,python,pyudev SLACKBUILD SHORT DESCRIPTION: solaar (Device manager for Logitech's Unifying receiver peripherals)

А знакомство с файлом /slkbuild/14.1/ChangeLog.txt не показывает следов активного обновления:

Sun Dec 01 2013system/solaar-0.9.2: Added. +-------------------------+ Wed Nov 27 2013 misc/pastebinit-1.3.1: Added.

Так что больше я к нему возвращаться не буду. Пока прошу только обратить внимание на строку SLACKBUILD REQUIRES: в описании слакбилдов для обоих пакетов.

А вот репозиторий sbo – это, как можно догадаться по названию, нечто вроде «филиала» SlackBuilds.org, не только повторяющего его структуру, но и во многом соответствующего ему по содержанию (с некоторыми купюрами).

Рисунок 8-3. Структура sbo-репозитория Salix

В чём же, кроме этих купюр, отличие? Дьявол, как известно, таится в мелочах. И в данном случае эта мелочь — файл SLACKBUILDS.TXT, представляющий собой описание репозитория. Точнее, даже одна строка в описании каждого слакбилда репозитория. И строка эта –

SLACKBUILD REQUIRES:

в которой перечисляются зависимости пакета, собираемого данным слакбилдом (если они у него есть, разумеется). Например, в файле salix.hostingxtreme.com/sbo/14.1/SLACKBUILDS.TXT последние строки описания слакбилда для пакета EMBOSS выглядят так:

SLACKBUILD MD5SUM: cc3fca80cb0618deb10fa0d29fe90e4bSLACKBUILD MD5SUM_x86_64: SLACKBUILD REQUIRES: jdk SLACKBUILD SHORT DESCRIPTION: EMBOSS (European Molecular Biology Open Software Suite)

Тогда как в файле slackbuilds.org/14.1/SLACKBUILDS.TXT аналогичные строки имеют вид:

SLACKBUILD MD5SUM: cc3fca80cb0618deb10fa0d29fe90e4bSLACKBUILD MD5SUM_x86_64: SLACKBUILD SHORT DESCRIPTION: EMBOSS (European Molecular Biology Open Software Suite)

Именно различие в одну строку и позволяет учитывать зависимости при использовании слакбилдов из официального репозитория Salix в отличие от репозитория SlackBuilds.org. Хотя сами по себе слакбилды в них ничем между собой не различаются – более того, это просто одни и те же слакбилды.

А теперь давайте посмотрим, как это выглядит на практике. Для чего рассмотрим утилиту slapt-src, специально предназначенную для работы со слакбилдами.

Утилита slapt-src

Как уже говорилось, утилита slapt-src – не специфичный для Salix инструмент. Однако именно в этом дистрибутиве она заиграла всеми своими красками – в первую очередь благодаря описанным в предыдущем разделе его официальным репозиториям.

Утилита slapt-src написана тем же автором – Язоном Вудвардом, что и slapt-get, и работает в том же стиле.

Конструкция её команды требует указания действия (action — аналог target в slapt-get), в большинстве случаев – аргумента, то есть имени slackbuild'а, и, возможно, опций. Полный список действий и опций можно получить командой

$ slapt-src --help

или просто запустив slapt-src в «голом» виде. В отличие от slapt-get, в этой утилите какждое действие и каждая опция имеют как полную, так и краткую форму – так, вместо --help можно ввести -h. Действия и опции сопровождаются кристально ясными описаниями (в том числе и на русском), так что я остановлюсь .

Порядок действий при использовании slapt-src – точно тот же, что и при работе с slapt-get. Первое действие – запуск команды

$ sudo slapt-src -u

которая скачает данные о слакбилдах из подключённых репозиториев. А затем – с помощью

$ slapt-src -l

просматривается список всех доступных слакбилдов или посредством

$ slapt-src -s slackbuildname

отыскивается нужный. При необходимости командой

$ slapt-src -w [или --show] pkgname

просматривается его описание. После чего можно приступать к сборке:

$ slapt-src -i slackbuildname

Имя слакбилда всегда совпадает с именем пакета, который собирается с его помощью.

Как обычно, всё сказанное проще проиллюстрировать на примере, что я сейчас и проделаю. В конце прошлого раздела было приведено описание слакбилда для пакета EMBOSS – вот он примером и послужит. Во-первых, в силу своей компактности. А во-вторых – как иллюстрация того, для каких пакетов в принципе можно обнаружить слакбилды. Что косвенно указывает, на кого, в том числе, ориентирован дистрибутив Salix (как, впрочем, и материнская Slackware).

Начинаем, разумеется, с поиска:

$ slapt-src -s EMBOSSEMBASSY:6.6.0 - EMBASSY (EMBOSS associated software) EMBOSS:6.6.0 - EMBOSS (European Molecular Biology Open Software Suite)

Теперь можно просмотреть информацию о пакете:

$ slapt-src -w EMBOSSИмя слакбилда: EMBOSS Версия слакбилда: 6.6.0 Категория слакбилда: academic/EMBOSS/ Описание слакбилда: EMBOSS (European Molecular Biology Open Software Suite) Файлы слакбилда:

EMBOSS.SlackBuild EMBOSS.desktop EMBOSS.info EMBOSS.png README References doinst.sh slack-desc Требования слакбилда: jdk

Что делается, в том числе, и для определения его зависимостей, которые мы видим последней строкой вывода. Однако это – процедура совсем не обязательная. Потому что если приступить к установке командой

$ sudo slapt-src -i EMBOSS

то нам о них тут же после ввода пароля напомнят – и не просто напомнят, а предложат установить:

Следующие пакеты будут установлены: EMBOSS Следующие зависимые слакбилды будут собраны и установлены: jdk Продолжить? [y/N]

И если согласился с предложением, начнётся скачивание обоих слакбилдов и их исполнение в том порядке, который требуется зависимостями.

Простота использования slapt-src усугубляется элементарностью его настройки: все его конфигурируемые параметры лежат в файле /etc/slapt-get/slapt-srcrc и сводятся к указанию каталога для сборки пакетов, их «выходному» формату и перечислению подключённых репозиториев. Однако к вопросу настройки я ещё вернусь в следующей части цикла, которая будет посвящена Sourcery – графической настройке над slapt-src.