3rd party build

Материал из ALT Linux Wiki

Данный текст содержит краткую инструкцию по сборке стороннего ПО для ALT Linux и рассчитан прежде всего на системных администраторов и devops-инженеров, у которых уже есть как опыт работы с GNU/Linux и пакетной системой RPM, так и навыки использования git и rpmbuild.

Что понадобится

  • Компьютер. Любой современный x86_64 с достаточным количеством оперативной памяти: 8 Гб - разумный минимум, 16 Гб - номинал, 32 Гб - хватит для любого пакета, существующего в репозитарии Sisyphus на момент написания этого текста (лето 2018 года).
  • Установленная система ALT. Если не знаете, что взять за основу, начните с https://www.altlinux.org/Starterkits/Download (небольшие сборки на базе стабильной ветки) или, если вы уверены в своей квалификации, https://www.altlinux.org/Regular (сборки на базе репозитария Sisyphus; он достаточно стабилен, но иногда (несколько раз в год) мы ухитряемся его поломать).
  • Пакеты hasher [хешер] и gear [гир]. Первый создает временную среду сборки с полностью чистой системой и запускает в ней rpmbuild, а второй автоматизирует сборку .src.rpm из git-репозитария. В общем, apt-get update && apt-get install hasher gear

Да, это многих удивляет, но в ALT Linux совместно с пакетной системой RPM используется APT. Причина этого банальна: давным-давно, когда возник вопрос о выборе пакетной системы и средства работы с репозитариями пакетов, было принято решение использовать лучшее из того, что тогда существовало.

Создаем пользователей

Для работы hasher нужны два дополнительных непривилегированных пользователя: первый является владельцем системных файлов внутри сборочной среды (подобно тому, как владельцем системных файлов в обычной системе является root), а от имени (и с правами) второго внутри сборочной среды запускается rpmbuild. В документации по hasher они называются rooter и builder, но hasher-useradd по умолчанию создает для пользователя vasya сателлитов vasya_a и vasya_b - то есть, "Вася-админ" и "Вася-сборщик". 

root@buildhost:~ # hasher-useradd vasya

Настраиваем hasher-priv

На данном этапе достаточно указать в файле /etc/hasher-priv/system всего три параметра: 

prefix=~:/tmp/.private
allow_ttydev=yes
allowed_mountpoints=/proc,/dev/pts

Настраиваем hasher для пользователя

Так как hasher постоянно создает и очищает сборочную среду, для ускорения сборки есть смысл использовать tmpfs. Да, на всякий случай: SSD мы проверяли, на них все тоже работает, но сам накопитель очень уж быстро "запиливается", да и по скорости доступа с оперативной памятью не сравнить.

Создаем каталоги: 

mkdir -pm755 ~/.hasher/repo ~/my_repo/{,S}RPMS

Для удобства доступа к локальному репозитарию делаем симлинки: 

ln -s ../../my_repo/RPMS ~/.hasher/repo/RPMS.hasher
ln -s ../../my_repo/SRPMS ~/.hasher/repo/SRPMS.hasher
ln -s . ~/.hasher/repo/x86_64

Создаем файл ~/.hasher/config такого содержания: 

packager="Vasily I. Pupkin <vasya@example.net>"
def_repo=/home/vasya/.hasher/repo
mountpoints=/proc
no_sisyphus_check="changelog firmware gpg kernel nvr packager perms"

Здесь немного неочевидной является строчка no_sisyphus_check: дело в том, что hasher изначально разрабатывался для сборки пакетов в репозитарий Sisyphus, и по умолчанию проверяет, насколько собираемый пакет соответствует требованиям этого репозитария. Большинство из этих проверок действительно необходимы, очень многие просто полезны, но некоторые из них сборщик, который не является участником ALT Linux Team (да, это рекурсивная аббревиатура!), пройти не сможет в принципе, и их в такой ситуации есть смысл отключить.

И, наконец, создаем рабочий каталог для hasher, если его еще нет - например, после перезагрузки сборочной машины. Для этого следует добавить в конфигурационный файл shell (например, ~/.bashrc или ~/.tcshrc) такую строчку: 

test -d ~/hasher || ln -sf `mktemp -d -t hasher.XXXXXXXX` ~/hasher

Проверяем настройку hasher

Самый простой способ - взять какой-нибудь небольшой (в том числе с не слишком развесистыми зависимостями) пакет из репозитария Sisyphus и попробовать собрать его локально: 

wget https://mirror.yandex.ru/altlinux/Sisyphus/x86_64/SRPMS.classic/nbd-3.2-alt1.src.rpm

NBD - это технология, позволяющее предоставить доступ к блочному устройству по сети; в данном случае нам этот пакет интересен лишь тем, что даже на совсем скромном ноутбуке полностью пересобирается за пару минут одной командой: 

time hsh -v nbd-3.2-alt1.src.rpm

Загляните в ~/my_repo/RPMS - там должны появиться файлы nbd-*.x86_64.rpm


Сборка из git-репозитария с помощью gear

Как известно, практически вся разработка ПО ведется с использованием git. Для того, чтобы выполнить сборку пакета, нужно как минимум создать архив с исходниками командой git archive, завернуть его в .src.rpm посредством rpmbuild, а потом отдать результат в hasher. Этот набор операций приходится выполнять при каждой тестовой пересборке, и совершенно неудивительно, что для него появилось средство автоматизации.

Это средство называется gear, и здесь мы рассмотрим только самый типовой способ его применения.

Допустим, того же nbd в репозитарии нет, или же нам не нравится, как он собран (в частности, многие сборщики грешат тем, что даже не пытаются минимизировать установочные зависимости собираемых ими пакетов), или, как в данном случае, он просто устарел (официальный сайт гласит, что сейчас самой свежей стабильной версией является 3.17, а в Сизифе, как мы видели выше, еще только 3.2). Вытягиваем его из внешнего git-репозитария: 

git clone https://github.com/NetworkBlockDevice/nbd

Теперь создаем новую ветку на базе нужного нам тега и переключаемся на нее - просто для того, чтобы все наши изменения были отделены от апстрима: 

git checkout -b sisyphus nbd-3.17

Теперь создаем .spec-файл примерно такого содержания: 

Name: nbd
Version: 3.17
Release: vp1
Summary: NBD utilities
License: GPL
Source0: %name-%version.tar.xz
URL: https://github.com/NetworkBlockDevice/nbd
Provides: %name-server = %version, %name-client = %version
BuildRequires: docbook-utils
BuildRequires: glib2-devel
BuildRoot: %_tmppath/%name-%version-root
Group: System/Base

%description
Network Block Device (CONFIG_BLK_DEV_NBD) management utilities

%prep
%setup -q -n %name-%version

%build
./autogen.sh
%configure \
  --enable-syslog \
  ;
%make

%install
rm -rf %buildroot
%make DESTDIR=%buildroot install
mv %buildroot%_bindir/* %buildroot%_sbindir/ \
&& rm -rf %buildroot%_bindir

%clean
rm -rf %buildroot %_builddir/%name-%version

%files
%defattr(-,root,root)
%_sbindir/*
%_man1dir/*
%_man5dir/*
%_man8dir/*

%changelog
* Sun Apr 01 2018 Vasily Pupkin <vasya@example.net> 3.17-vp1
- updated to 3.17

Обратите внимание на параметры Release: и BuildRoot: - в первом используются инициалы нашего сборщика, что позволяет отличать его пакеты от апстримных altN, а второй на самом-то деле не особо и нужен, так как сборочная среда внутри hasher все равно его переопределяет, но мы на всякий случай оставляем возможность собрать наш пакет и для любой другой системы, использующей RPM. Аналогично можно было бы обойтись и без секции %clean, так как hasher после успешной сборки удалит не только эти каталоги, но и весь сборочный контейнер.

И в качестве финального штриха создаем простейший конфигурационный файл для gear: 

echo 'tar.xz: .' > .gear-rules

Дальше все стандартно: 

git add --all .
git commit -m 'prepare for automated build'

Все, можно запускать сборку: 

time gear-hsh --commit --verbose

Автор данного описания настолько часто использует эту команду, что создал для нее алиас, который называется просто gh - то есть, "gear-hsh с моими любимыми параметрами".