Сборка пакетов в ALT Linux. Данный текст рассчитан на системных администраторов и devops-инженеров, у которых уже есть как опыт работы с GNU/Linux и пакетной системой RPM, так и навыки использования git и rpmbuild. 0. Что понадобится. * Компьютер. Любой современный 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. Причина этого банальна: давным-давно, когда возник вопрос о выборе пакетной системы и средства работы с репозитариями пакетов, было принято решение использовать лучшее из того, что тогда существовало. 1. Создаем пользователей. Для работы hasher нужны два дополнительных непривилегированных пользователя: первый является владельцем системных файлов внутри сборочной среды (подобно тому, как владельцем системных файлов в обычной системе является root), а от имени (и с правами) второго внутри сборочной среды запускается rpmbuild. В документации по hasher они называются rooter и builder, но hasher-useradd по умолчанию создает для пользователя vasya сателлитов vasya_a и vasya_b - то есть, "Вася-админ" и "Вася-сборщик". root@buildhost:~ # hasher-useradd vasya 2. Настраиваем hasher-priv На данном этапе достаточно указать в файле /etc/hasher-priv/system всего три параметра: prefix=~:/tmp/.private allow_ttydev=yes allowed_mountpoints=/proc,/dev/pts 3. Настраиваем 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/`uname -m` Создаем файл ~/.hasher/config такого содержания: packager="Vasily I. Pupkin " 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 4. Проверяем настройку 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 5. Сборка из 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 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 с моими любимыми параметрами". P.S.: автор считает необходимым еще раз напомнить, что данный текст адресован прежде всего системным администраторам и devops-инженерам, которые занимаются сопровождением разработки ПО для ALT Linux. К сожалению, приведенной здесь информации заведомо недостаточно для выполнения работы мейнтейнера пакета, а некоторые из рекомендаций (особенно про отключение проверок Sisyphus) способны вызвать у участников проекта реакцию в диапазоне от презрительного фыркания до сердитого рычания, но создание полного руководства мейнтейнера заняло бы существенно больше времени, так как это уже была бы не короткая статья, а полноценный учебник.