Сборка пакетов (etersoft-build-utils)

Краткая инструкция по сборке пакетов с помощью etersoft-build-utils

Здесь рассмотрена процедура сборки RPM-пакетов для ALT Linux. Это облегчённая инструкция для начинающих разработчиков, написанная с учётом использования пакета etersoft-build-utils. Обратите внимание, что команды из состава этого пакета всегда выводят те команды, которые используются для выполнения задачи. Это может помочь для понимания сути процесса.

Первоначальная настройка

С правами root

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

# epm install etersoft-build-utils

Данный пакет «вытянет» по зависимостям всё остальное, обычно необходимое при сборке.

Под пользователем

Настройки для подписи пакетов

Записываем данные о сборщике в файле ~/.rpmmacros по следующему образцу:

%_topdir        %homedir/RPM
%_tmppath       %homedir/tmp
%_gpg_path      %homedir/.gnupg
%_gpg_name      Vitaly Lipatov <lav@altlinux.org>
%packager       Vitaly Lipatov <lav@altlinux.org>

Если вы являетесь мантейнером, то для того, чтобы подписывать пакеты и отправлять их для сборки в Сизиф, вы должны указать адреса, под которым вы зарегистрированы в ALT Linux Team.

Настройки для создания git-коммитов

Для того, чтобы у создаваемых вами git-коммитов был правильный пользователь (будет применяться также и для подписи тэгов сборки):

$ git config --global user.email dottedmag@altlinux.org
$ git config --global user.name "Mikhail Gusarov"

Если у этого имени нет совпадения с gpg-ключом, можно задать его отдельно:

$ git config --global user.signingkey "<ID ключа GPG для подписи тэгов>"

Чтобы узнать свой user.signingkey, выполните команду

$ gpg --list-secret-keys

Искомое значение находится в секции sec. Его-то и следует прописать в переменную user.signingkey, предварительно снабдив символами 0x

В итоге должна получиться команда такого вида:

$ git config --global user.signingkey 0xA26F54C8

Внесённые данные хранятся в ~/.gitconfig и их всегда можно исправить.

Настройки для доступа к git-репозиторию и сборочнице

Доступ к gitery (git-сервер) и gyle (сборочный сервер) осуществляется через git. Вам нужно будет внести настройки в '~.ssh/config по образцу, заменив USERNAME на свой логин:

 # Гитовница
   Host gitery
     HostName gitery.altlinux.org
     User alt_USERNAME # а не просто USERNAME!
     Port 222

 # Сборочница
   Host gyle
     HostName gyle.altlinux.org
     User alt_USERNAME # а не просто USERNAME!
     Port 222

Сборка пакетов

Образец того, как надо оформлять спек, вы можете посмотреть в пакете wcalc или gnubiff. Настоятельно рекомендуется обратиться к документации, а также смотреть «как это сделано в другом пакете».

Основываясь на существующем пакете

Получить git-репозиторий по названию исходного пакета можно командой

$ rpmgp -g название_пакета

Можно взять за основу пакет, собранный в стороннем репозитории. Поискать поможет

$ rpmgp -a название

Загрузить:

$ rpmgp -a -d <полная строка с названием пакета>

Создать git-репозиторий из пакета src.rpm:

$ rpmgp -m пакет.src.rpm

Создание репозитория пакета с нуля

Сначала создаём каталог и инициализируем в нём git-репозиторий:

mkdir mypackage && cd mypackage && git init

Минимально в репозитории должен присутствовать файл .gear/rules с правилами упаковки тарбола. Обычно его минимальное содержимое таково:

tar: @name@

и спек с названием mypackage.spec.

Имеются образцы спеков для разных типов пакетов.

На всё богатство уже существующих спеков можно любоваться здесь: https://github.com/altlinux/specs или на сайте https://packages.altlinux.org .

Типовые действия при сборке

rpmbb

для сборки пакета (он будет записан в ~/RPM/RPMS)

add_changelog название.spec

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

Ошибки при сборке

Для начала, нужно локализовать проблему — определить, является ли она проблемой конкретного дистрибутива/системы (например: отсутствие или неверная версия необходимых для сборки библиотек, специфика дистрибутива) или более глобальной (например: несобираемость определённой версией компилятора, ошибки в коде, несоответствие кода новым стандартам). В первом случае, поможет осуществить поиск по дистрибутиву/репозиторию, поискать решение проблемы в архивах почтовых рассылок или непосредственно попросить помощи в рассылке (sisyphus, devel, community).

Во втором случае, стоит начать с поиска готовых решений. В открытом сообществе, считается хорошим тоном публиковать решения найденных проблем. Зачастую, поисковики выдают море полезной информации по кратко описанной в трёх-пяти словах проблеме конкретного софта или тексту ошибки, полученной при сборке. Например, запроса вида «gcc4.1 mysoftware patch» может быть достаточно для поиска патча, решающего проблему сборки с новым gcc4.1).

Стоит также ознакомиться с другими репозиториями с пакетами открытой разработки. Зачастую там уже сталкивались с подобными проблемами, и у них есть готовое решение (патч).

Поиск пакетов

Возможно при сборке вам придётся доустанавливать недостающие библиотеки. Имейте в виду, что в ALT принято называть пакеты для разработки так: libX-devel, где X — название библиотеки.

Используйте

epm search название

для поиска недостающего пакета или

epm sf слово

для поиска по файлам, содержащимся в пакетах.

Сборочная среда Hasher

Чтобы убедиться в том, что все зависимости правильны и сборка вашего пакета нормально пройдёт на сборочном сервере в ALT Linux, используется Hasher — среда, которая позволяет осуществить сборку пакета в «чистой» системе, куда установлены только пакеты, указанные в сборочных зависимостях.

Под рутом

Устанавливаем hasher:

# epm install hasher

Перед использованием сборочной среды hasher нужно добавить специальных пользователей hasher:

# hasher-useradd <ваш_логин>

Далее выйдите из системы (logout) и зайдите обратно (hasher-useradd изменяет список групп, в которых состоит пользователь).

Сборка

Для сборки пакета в hasher запускаем

rpmbsh -i

Эта команда соберёт пакет и установит его в тестовый hasher, где его можно будет проверить на работоспособность.

Обратите внимание, что сборка в hasher не учитывает незакоммиченные в репозиторий изменения. Возможны следующие варианты: rpmbsh -t (запустить сборку с учётом незакоммиченных изменений) или gamend (прилепить незакоммиченные изменения к последнему коммиту.

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

rpmbsh -l

-l — не очищать окружение после сборки

далее повторные сборки запускать с параметром -e:

rpmbsh -e

будет использовано уже созданное сборочное окружение.

Дополнительная документация

При сборке пакетов сверяйтесь со следующей документацией: