LXF97:Hardcore Linux

Материал из Linuxformat.

Gentoo: Не жди ebuild’ов!

Необходимо самое свежее ПО, еще не попавшее в portage? Нейл Ботвик покажет пользователям Gentoo, как отследить ebuild или написать свой собственный.

Кроме рассылки своевременных ответов на вопросы озадаченных пользователей через форумы http://www.linuxformat.co.uk, наибольшее удовлетворение от работы в Linux Format нашей команде приносят ответы на избранные запросы наших читателей, присылаемые на наши адреса. Мы хотим лишь одного: чтобы у нас было побольше времени на помощь!

Уважаемый Linux Format,

В вашем обзоре Gentoo сказано, что в нем почти 12 000 пакетов, и они всегда свежие, так почему же я не могу установить новую версию Snafu 2.0?

Брюзга из киберпространства

Уважаемый/ая г-н/г-жа Брюзга,

Действительно, пакетов для Gentoo очень много: сейчас есть более 24 000 ebuild’ов для более 12 000 пакетов; но нет такого репозитория, где содержится абсолютно все. Однако Вы можете заполучить Snafu хоть сию же минуту, причем не одним способом. Так что давайте рассмотрим некоторые способы его найти, или даже, если ни один не поможет, напишем свой собственный ebuild, что не так страшно, как Вам может показаться. Заодно мы рассмотрим несколько полезных программ, которые делают работу с portage еще легче.

Я случайно подметил, что Вы пожаловались лишь на сравнительно малоизвестную программу Snafu; более известные foo и bar всегда идут в ногу со временем, поскольку они необходимы для корректной работы большинства man-страниц. Читайте... НБ

Шагать в ногу со временем

Если последнюю синхронизацию portage вы проводили раньше, чем вчера, то запустите emerge --sync, чтобы убедиться в наличии всех свежих обновлений, содержащих то, что вам необходимо. Если Snafu 2.0 все еще нет и он был выпущен менее чем месяц назад, весьма вероятно, что он уже есть в portage, но помечен для тестирования. Большинство ebuild’ов находятся в дереве около 30 дней, прежде чем их пометят как стабильные; очевидное исключение – исправления безопасности, которые поставляются всем при первой же возможности. Управляет этим параметр KEYWORDS,

KEYWORDS=”x86 ~amd64”

означающий, что ebuild рассматривается как стабильный для x86, но все еще тестируется для amd64. И вам не нужно закапываться в ebuild’ы, чтобы это обнаружить! Первая полезная программа уже здесь, она называется eix, вот ее и emerge’ните. Это программа поиска в portage, она в несколько раз быстрее, чем использование emerge --search, и к тому же предоставляет больше информации. Быстротой она обязана использованию индексов, так что после ее установки запустите update-eix. Базу данных необходимо обновлять каждый раз при запуске emerge --sync; программа eix-sync позаботится об обеих задачах и сообщит вам о новых и обновленных пакетах. Теперь выполните eix некая_программа, и увидите, что есть в portage. Вывод eix четко различает стабильные, тестовые и маскированные (об этих далее) пакеты. Версия пакета, устанавливаемого portage, управляется параметром ACCEPT_KEYWORDS в вашем /etc/make.conf, но его можно назначить самим. При желании установить тестовый пакет, выполните

ACCEPT_KEYWORDS=”~amd64” emerge snafu

но это должно использоваться только с --pretend, для тестирования. Имеются по меньшей мере две веские причины не использовать ACCEPT_KEYWORDS в командной строке. Во-первых, это будет применено ко всем устанавливаемым пакетам: не только к Snafu, но и к его зависимостям. Во-вторых, установка является временной, и при следующем emerge world portage попытается вернуть все назад. Решение – в etc/portage/package.keywords. Файлы в /etc/portage отменяют для отдельных пакетов настройки в make.conf и профиле portage. Итак, поместите следующую строку net-misc/snafu ~amd64 в /etc/portage/package.keywords (если файл не существует, создайте его), и будете всегда использовать тестовую версию Snafu. Можно выполнить болеетонкую настройку, применив ее к конкретной версии; можно предпочесть тестовую версию Snafu 2.0 и остановиться на ней, когда она станет стабильной, а не гнаться постоянно за новыми версиями; более детально см. врезку под заголовком «Атомная сила».

 =net-misc/snafu-2.0
 >net-misc/snafu-2.0
 <net-misc/snafu-2.0
~net-misc/snafu-2.0

Возможно также, что пакет просто не был протестирован на вашей архитектуре, и ebuild не содержит ключевых слов для нее. Обычно это случается со второстепенными архитектурами, но порой имеет место и для amd64. Часто вы можете заставить его установиться, изменив ACCEPT_KEYWORDS на значение ~x86 или x86 для этого пакета. Если таким образом все устанавливается и корректно запускается, отправьте отчет на http://bugs.gentoo.org, чтобы осуществляющие поддержку знали это. Я так поступал много раз, когда устанавливал на свой iBook программы, не тестированные для PPC.

Другой вариант – пакет замаскирован; тогда присвоение ему ключевых слов ни при чем. В этом случае пакет (обычно) приведен в списке /usr/portage/profiles/package.mask, вместе с причинами маскирования. Причина может быть любой: от «замаскирован для тестирования» до «подпалит вашего кота, если установите». Если вы готовы к подобным последствиям, добавьте атом пакета в /etc/portage/package.unmask, чтобы установить его.

Прежде чем оставить тему тестовых и стабильных ebuild, важно уяснить, что эти термины означают. Они соответствуют самому ebuild. Стабильный ebuild тестировался около месяца и потому стабилен, и в смысле доказательства работоспособности и в смысле других определений стабильности, и неизменяем. Это важное свойство стабильных пакетов: вам не надо обновлять вашу машину бесконечно, что важно на производстве. Тестовый, с другой стороны, не означает нестабильный, в смысле склонный к сбоям: это означает более быстрое изменение. Очень важно, что эти термины применяются к ebuild, но не к программам, которые они устанавливают. Хотя ebuild Snafu 2.0 еще не помечен как стабильный, это не означает, что сама Snafu считается нестабильной, склонной к повреждению вашего компьютера или вызывающей выпадение волос.

Забираемся глубже

Хотя дерево portage – это главный репозиторий ebuild’ов, он отнюдь не единственный. Portage позволяет добавлять оверлеи, содержащие больше ebuild’ов. Если вы добавите строку

PORTDIR_OVERLAY=/usr/local/portage

в /etc/make.conf и создадите этот каталог, вы сможете копировать ebuild’ы в него. Где их найти? Первым делом обратитесь на сайт Gentoo, где регистрируются ошибки [bug tracker] – http://bugs.gentoo.org. Поищите по имени программы с префиксом ALL, чтобы убедиться, что просмотрены будут все ошибки, а не только открытые – например, ALL snafu. Вы можете обнаружить, что кто-то уже написал ebuild или изменил существующий, если он обновляется. Если нет, можете зарегистрировать ошибку с запросом на ebuild. Если вы ищете обновление программы, находящейся в portage, то дайте разработчикам время отреагировать на ваш запрос – не размещайте запросов на обновления через час после выхода программы. После Bugzilla, посмотрите на домашней странице программы – некоторые авторы выпускают свои собственные ebuild’ы; а не то поищите на форумах Gentoo.

Найдя ebuild, скопируйте его в соответствующее место вашего оверлея; при именовании должны использоваться стандартные категории, определенные для portage, так что ваш ebuild Snafu 2.0 следует разместить в /usr/local/net-misc/snafu/snafu-2.0.ebuild. Если вы не смогли назвать его правильно, то portage, вероятно, проигнорирует его. Обычные предостережения касаются программ, поступающих из неофициальных источников: если они что-то сломают, вам останутся осколки и ничего более.

Обновление существующего ebuild’а

Если вы собираетесь обновить существующий пакет, часто вы можете установить его, сделав копию существующего ebuild’а. Поскольку ebuild’ы используют другие файлы внутри каталога пакета, наилегчайший путь сделать это – скопировать весь каталог пакета с /usr/portage в ваш оверлей, затем скопировать ebuild, например:

cp -a /usr/portage/net-misc/snafu /usr/local/portage/net-misc/
cd /usr/local/portage/net-misc/
cp snafu-1.5-r1.ebuild snafu-2.0.ebuild

Выберите для копирования последний из существующих ebuild’ов. Часто ebuild’ы не требуют какой-либо правки, благодаря способу, которым portage получает информацию о версии из имени ebuild. Скопированный ebuild будет знать, что нужно загрузить snafu-2.0.tar.bz2 со страницы проекта на SourceForge. Если вы сделаете это и он заработает, пожалуйста, сообщите об успехе разработчикам на http://bugs.gentoo.org – пусть знают, что он работает. Прежде чем работать с пакетом, добавленным вами к вашему оверлею, следует создать для него файл манифеста. Он содержит хэши MD5 и SHA1 всех файлов в каталоге пакета (а файлы в официальном дереве имеют также GPG-подпись). Это сделано для предотвращения вторжений malware под видом ebuild и означает, что portage откажется устанавливать пакет, если детали его манифеста не совпадают. Для ваших оверлейных ebuild’ов вам необходимо создать манифест самостоятельно, при помощи

ebuild /usr/local/portage/net-misc/snafu-2.0.ebuild manifest

Сторонние оверлеи

Оверлей portage вы можете создать сами, а можете во множестве импортировать их из других мест. Когда-то для этого приходилось использовать cvs или subversion, а затем редактировать /etc/make.conf, но сейчас у нас есть layman – один из полезных инструментов, о которых я говорил ранее: пришла пора его установить. Готово? Теперь выполните

layman -L

для загрузки и отображения последнего списка оверлеев. Список, правда, не слишком информативен: как узнать, какой оверлей содержит требуемый пакет? Вспомним eix. Он умеет загружать индексы также и из layman: выполните

update-eix-remote

и при следующем поиске с использованием eix выведется также и список пакетов, найденных в оверлеях. Добавьте этот оверлей в вашу систему так:

layman -a overlayname

Когда вы делаете это в первый раз, вам следует добавить следующую строку в /etc/make.conf

source /usr/portage/local/layman/make.conf

Она известит portage обо всех добавленных layman оверлеях, так что вы сможете устанавливать из них через emerge. Один из первых рассматриваемых оверлеев – Sunrise (http://overlays.gentoo.org/proj/sunrise), содержащий избранные ebuild’ы с http://bugs.gentoo.org, онближе всех к официальному оверлею.

Ваш первый ebuild

Вы пытались переименовать старый ebuild (если это обновление), искали в http://bugs.gentoo.org, http://forums.gentoo.org, в Google и под кроватью, но ebuild для вашего пакета так и не нашелся. Есть еще одна возможность: написать ebuild самостоятельно. Спешу вам сообщить, пока вы в ужасе не отбросили журнал, что написание ebuild для Gentoo намного проще, чем создание RPM- или Deb-пакетов, потому что большую часть работы выполняет portage. Если пакеты для сборки и установки используют стандартный автоматический процесс ./configure && make && make install, то процедура практически тривиальна.

Вы найдете шаблоны ebuild в /usr/portage/skel.ebuild, они почти целиком состоят из пояснительных комментариев. Ebuild – это скрипт bash, управляющий загрузкой, распаковкой, конфигурированием, ком- пиляцией и установкой программ. Portage использует множество функций для выполнения этих задач, главные из которых – src_fetch(), src_compile() и src_install(). Вы можете определить их в вашем ebuild, но если этого не сделать, то определения по умолчанию работают в стандартном случае ./configure && make && make install. Получается, что простейший ebuild – просто набор присвоений значений переменным, вроде

# Copyright 1999-2007 Gentoo Foundation
 # Distributed under the terms of the GNU
 General Public License v2
 # $Header: $
 DESCRIPTION=”Snafu is a great program”
 HOMEPAGE=”http://www.snafu.con/”
 SRC_URI=”http://www.snafu.con/downloads/${P}.tar.bz2”
 LICENSE=”GPL-2”
 SLOT=”0”
 IUSE=””
 KEYWORDS=”~x86”

Три первые строки необходимы, если вы отправляете свой ebuild на http://bugs.gentoo.org. Остальные переменные обязательны, а имена их по большей части говорят сами за себя. DESCRIPTION, HOMEPAGE и LICENSE (используется американская орфография) очевидны, за исключением того, что значение LICENSE должно быть одним из указанных в /usr/portage/licenses. SRC_URI – это расположение tar-архива с исходными текстами, $P соответствует имени ebuild’а без расширения .ebuild и любых частей -rN. Именно поэтому переименование ebuild автоматически заставляется загружать и устанавливать новую версию программы, версия и имя tar-архива берется из имени ebuild. SLOT – обязательный параметр, он обычно равен нулю, что означает, что пакет не множественный [slotted]. Слоты – это способ установки двух, обычно несовместимых, версий одного и того же пакета. Они необходимы, когда различные программы зависят от отличающихся версий. Чтобы увидеть множественные пакеты, выполните

 equery list --duplicates

Equery – еще одна из полезных программ, которую следует установить, она является частью пакета gentoolkit. Присутствие IUSE также обязательно, хотя переменная может быть оставлена пустой, в отличие от SLOT; она содержит список флагов USE, соответствующих ebuild. KEYWORDS также не требует пояснений (по крайней мере, если вы читаете этот урок нормально, от начала к концу) и должна иметь значения только тех архитектур, для которых известно, что программа работает. Если вы знаете, что программа не работает на конкретной архитектуре, вам следует предварить ее в KEYWORDS знаком - (минус).

 KEYWORDS=”~x86 amd64 -ppc”

означает, что вы протестировали его на трех архитектурах, и он заработал только на первых двух. Любая не указанная архитектура считается не протестированной.

flagedit net-misc/snafu usb
flagedit net-misc/snafu -usb
flagedit net-misc/snafu %usb

Следующий шаг

Все, чем мы покамест занимались на нашем уроке – это чрезвычайно простой ebuild, даже не рассматривающий фиксированные зависимости, не говоря уж о различных опциях и зависимостях, управляемых флагами USE. Давайте его немного дополним. Portage различает зависимости времени компиляции, те, что необходимы только при сборке программы, и зависимости времени исполнения. Они указываются в переменных DEPEND и RDEPEND соответственно, и часто совпадают. Ebuild для Snafu может содержать

DEPEND=”dev-libs/libusb
  media-libs/libpng
  >=app-misc/unfoo-1.0.5”
RDEPEND=”${DEPEND}”

Заметьте, что мы можем указать соответствующую версию пакета. А что если Snafu поддерживает USB опционально? Ясно, что это встроено в программу, так что с ней уже ничего не сделаешь, но давайте предположим, что в ней имеется опция «не работать с USB-устройствами», и мы хотим использовать эту возможность при ее установке. Именно для этого и существуют флаги USE. Нам необходимо добавить в ebuild три вещи: сообщение, какие флаги USE следует учитывать, учет всех зависимостей, затрагиваемых флагами USE, и пересылку соответствующих опций в конфигурационный скрипт программы, примерно так:

IUSE=”usb”
DEPEND=”usb? (dev-libs/libusb)
  другие зависимости...”
src_compile() {
  econf \
   $(use_enable usb)
  emake || die “Make failed”
}

flag? (atom) в DEPEND означает «если флаг установлен, добавить атом к зависимостям». Поскольку мы меняем опции конфигурации, нельзя использовать стандартную функцию src_compile(), которая по существу запускает econf для вызова ./configure, а затем emake для запуска make; обе они являются некоторыми специфичными для portage улучшениями. Мы всего лишь добавляем дополнительные опции в ./configure. Функция use_enable проверяет, установлен ли флаг USE, и если да, то выводит --enable-flagname. Если в каталоге с исходными текстами snafu вы выполните ./configure --help, как при установке из исходных текстов вручную, то увидите список опций. Если опция для включения поддержки USB – это --enable-usb, то добавление $(use_enable usb) в econf означает, что ./configure вызывается с этими опциями. А если вместо этого конфигурационный скрипт использует - -enable-libusb? Вы можете определить любую разрешенную строку для использования вместо названий флагов при помощи econf $(use_enable usb libusb)

Некоторые конфигурационные скрипты используют --with-option вместо --enable-option; в этом случае замените use_enable на use_with. Если вы emerge’ите пакет при помощи USE=“-usb”, то configure будет запущен с --disable-usb или --without-usb.

Классный код

Базовые функции ebuild, такие как src_compile, доступны для всех ebuild’ов, но существует множество других функций, используемых группами ebuild, которые вы также можете использовать. Они называются eclasses и содержатся в /usr/portage/eclasses; их можно добавить в ваш ebuild путем включения

inherit имя_класса

в самом начале. Наиболее распространена из них eutils, используемая огромным числом ebuild’ов, но также имеются и классы для программ определенных типов, так что если вы пишете ebuild для программы KDE, посмотрите различные kde eclasses. Сами eclasses содержат пояснительные комментарии, но вам не мешает обратиться к app-portage/portage-manpages за дополнительной документацией. Другие места, где можно разжиться подробной информацией – man-страницы ebuild и portage, а также Руководство разработчика Gentoo на http://devmanual.gentoo.org.

Это лишь кратчайшее введение в ebuild, но вполне достаточное, чтобы вы могли начать, и оно показывает, что написать простой ebuild очень просто, потому что разработчики portage уже сделали всю трудную работу за вас. Все равно что в кулинарном рецепте указывать только ингредиенты, будучи счастливым владельцем целого персонала поваров, которые умеют готовить блюдо. LXF

Полезные утилиты

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

• eix - Уже описывался: это самый быстрый и гибкий инструмент поиска в portage.

• gentoolkit & gentoolkit-dev - Gentoolkit содержит несколько полезных утилит: equery для запроса информации о пакетах, revdep-rebuild для поддержания системы в порядке, glsa-check следует запускать после каждой синхронизации для проверки предупреждений по безопасности, eclean может вернуть свободное место путем удаления уже не нужных tar-архивов. Gentoolkit-dev содержит еще несколько утилит для работы с ebuild’ами, в основном ориентированных на создание ebuild’ов для распространения.

• genlop - Это синтаксический анализатор файла emerge.log, не особо замечательный, но он может откопать любую информацию об установленных пакетах и даже предоставить оценку времени до завершения текущего emerge.

• portage-utils - Здесь содержатся программы ‘Q’, выполняющие схожие с equery функции. Альтернатива Q работает быстрее, но equery имеет больше функций, так что устанавливайте обе.

• layman - Уже описывалась; если вы хотите использовать ebuild’ы с оверлеев, layman намного упростит управление ими.

• sufed, profuse и flagedit - Это редакторы флагов USE; ufed и profuse – интерактивные редакторы, работающие с глобальными флагами, отображая информацию о каждом флаге и позволяя включать их или выключать. Flagedit – только для командной строки, он подразумевает, что вы уже знаете, чего хотите, но также работает с ключевыми словами [keyword] и с установками для каждого пакета в /etc/portage.