архив
Zenwalk
Приобщение к Linux
2008-06-25
Сборка пакетов «в лоб»
Ручная сборка пакетов из исходников — самый универсальный метод установки любого программного обеспечения. Собственно, в мире Open Source он единственно универсален — все прочие способы привязаны к тому или иному дистрибутиву или определенной системе управления пакетов или их построения.
В силу своей универсальности методы ручной сборки описывались бессчетное число раз. В частности, весьма подробно они освещены на страницах книги про POSIX'ивизм. Что избавляет меня от необходимости вдаваться в детали — остановлюсь только на ключевых моментах, необходимых для понимания специфики системы построения пакетов дистрибутива Zenwalk.
Процедура сборки пакета из исходных текстов в общем случае сводится к выполнению следующих действий:
- получению архива исходников,
- распаковке его и
- собственно сборке.
Исходные тексты почти всех программ в мире Open Source распространяются в виде архивов, собранных утилитой tar и компрессированных посредством программ сжатия gzip или bzip2, то есть архивные файлы имеют примерно такой вид:
pkg_name-version-release.tar.gz
или
pkg_name-version-release.tar.bz2
соответственно. Иногда можно встретить архивные файлы в форме *.tgz или *.tbz — это те же самые «загзипленные» или «забзипленные» tar-архивы, переименованные для видимости в операционных системах, признающих имена файлов только по формуле 8.3 или не воспринимающих в именах множественных точек.
Получаются такие архивы, как правило, с авторских сайтов разработчиков (т.н. мастер-сайтов) или с серверов типа Sourceforge и им подобных, которые, при знании имени пакета, легко находятся с помощью Google. На худой конец, адреса мастер-сайтов всегда можно подсмотреть в портах FreeBSD, портежах Gentoo или пакетах Debian — этими системами окучен практически весь мир свободных исходников.
Распаковка архива осуществляется обычным образом:
$ tar xzfv path2/pkg_name-version-release.tar.gz
или
$ tar xjfv path2/pkg_name-version-release.tar.bz2
в зависимости от применявшейся утилиты компрессии. В большинстве случаев авторы пакетов предусматривают распаковку их архивов в собственный подкаталог типа ./pkg_name или ./pkg_name-version-release. Если в этом нет уверенности, во избежание захламления текущего каталога это лучше проверить:
$ tar tzfv path2/pkg_name-version-release.tar.gz
или
$ tar tjfv path2/pkg_name-version-release.tar.bz2
В графической среде (типа умолчальной для Zenwalk'а Xfce) для просмотра содержимого архивов и их распаковки можно воспользоваться программой Xarchiver — она же вызывается при щелчке мышью на файлах вида *.tat.gz или *.tar.bz2 в файловом менеджере Thunar.
После распаковки архива пакет остаётся только собрать. Для чего переходим в каталог, образовавшийся после распаковки архива и для начала внимательно читаем (почти наверняка) имеющиеся там файлы типа README и (или) INSTALL. Что позволяет удостовериться в том, что нам предстоит последовательно выполнить три магических действия — команды
$ ./configure $ make $ make install
Первая команда — это сценарий конфигурирования, находящийся в текущем каталоге пакета (почему и запускается с явным на то указанием — ./configure). В его задачу входит проверка установленных в системе компонентов, необходимых для сборки и функционирования собираемого пакета — пресловутых зависимостей. Если таковые оказываются на месте, можно приступать к следующей фазе процесса.
В противном случае последует более или менее внятное сообщение об ошибке, внимательное чтение которого обычно позволяет установить её причину; как правило, это отсутствие каких-либо библиотек, позарез необходимых нашему пакету (то есть нарушение «жестких» зависимостей).
Некоторые сценарии конфигурирования отслеживают также «мягкие» зависимости и любезно сообщают, какой функциональности собираемого пакета мы лишимся, если их не удовлетворим (например, поддержки мыши в консольных приложениях при отсутствии службы gpm, возможности печати или сканирования при отсутствии систем cups и sane соответственно).
Сценарий конфигурирования обычно предусматривает возможность указания необязательных опций. Наиболее часто используются флаги оптимизации для компилятора gcc, такие как CFLAGS И CXXFLAGS, опция prefix, переопределяющая корневой каталог для установки компонентов пакета (по умолчанию в этом качестве почти всегда выступает /usr/local), а также подключение или отключение дополнительных функций посредством опций with/without и enable/disable. Однако это тема совершенно особого разговора, которому здесь не место; заинтересованных отсылаю к главе 14 всё того же Введения в POSIX'изм.
Однако предположим, что зависимости мы или удовлетворили, или, если говорить о «мягких» зависимостях, проигнорировали. Теперь наступает время команды make, которая выполняет компиляцию бинарных файлов из исходных текстов и, в необходимых случаях, связывание их с функциями соответствующих библиотек (так называемую линковку, linking). Результатом будет появление в текущем каталоге или его подкаталогах исполняемого бинарника пакета и всех сопутствующих файлов типа man-страниц и прочей документации, примеров конфигурационных файлов и так далее.
На стадии сборки также возможны ошибки, обычно связанные с несоответствием версий библиотек и (или) компилятора (например, несоответствующим определением функций). Однако они решаются, скорее всего, только вмешательством в исходники, что мы здесь обсуждать не будем. А оптимистично предположим, что сборка завершилась благополучно и дадим команду
$ make install
В отличие от предыдущих команд, которые могут быть выполнены обычным пользователем, эта требует полномочий администратора. Ибо она выполняет очень простую, но важную функцию: видоизменяет файловую иерархию за пределами домашнего каталога, копируя собранные компоненты пакета в надлежащие места — по умолчанию, как уже говорилось, это почти всегда подкаталоги внутри /usr/local, такие как /usr/local/bin/, /usr/local/man, /usr/local/share и так далее. На этом сборку пакета можно считать законченной и приступать к его использованию.
По описанной схеме собирается, наверное, 99% всех пакетов, распространяемых в исходниках. Исключения редки. Например, пакет может быть настолько прост, что не требует предварительного конфигурирования. Или же в нем не предусмотрена автоматическая инсталляция — пользователю предоставляется право самому поместить исполняемые бинарники сотоварищи в те каталоги, которые он полагает для них подходящими. Все такие случаи, как правило, документированы в файлах README и INSTALL, почему и рекомендуется начинать сборку с их чтения.