Hasher/Руководство

hasher — инструмент для сборки пакетов в «чистой» и контролируемой среде. Это достигается с помощью создания в chroot минимальной сборочной среды, установки туда указанных в source-пакете сборочных зависимостей и сборке пакета в свежесозданной среде. Для сборки каждого пакета сборочная среда создаётся заново [1] .

Такой принцип сборки имеет несколько следствий:

• Все необходимые для сборки зависимости должны быть указаны в пакете. Для облегчения поддержания сборочных зависимостей в актуальном состоянии в Sisyphus придуман инструмент под названием buildreq,
• Сборка не зависит от конфигурации компьютера пользователя, собирающего пакет, и может быть повторена на другом компьютере,
• Изолированность среды сборки позволяет с лёгкостью собирать на одном компьютере пакеты для разных дистрибутивов и веток репозитория — для этого достаточно лишь направить hasher на различные репозитории для каждого сборочного окружения.

Дополнительно к сборке пакетов hasher

• проверяет их с помощью утилиты sisyphus_check,
• создаёт локальный APT-репозиторий с результатами сборки, позволяя последовательно собирать пакеты, опираясь на уже собранныевнимание: в hasher-1.3.17-alt1 произведена оптимизация, вследствие которой по умолчанию хэши не генерируются (используется rpm-dir); при необходимости в них предлагается воспользоваться $workdir/aptbox/regenbasedir .

Установка [ править ]

hasher в Sisyphus и дистрибутивах ALT Linux располагается в пакетах hasher, hasher-priv и легко устанавливается:

Добавление пользователя [ править ]

hasher использует специальных вспомогательных пользователей и группу hashman для своей работы, поэтому каждого пользователя, желающего использовать hasher, перед началом работы нужно зарегистрировать:

Эта команда создаёт вспомогательных пользователей USER_a и USER_b и добавляет пользователя USER в группы hashman, USER_a и USER_b.

Поскольку hasher-useradd добавляет пользователя в группы, пользователю необходимо перелогиниться (открытия нового терминала в X недостаточно; su - $USER достаточно) перед началом работы с hasher.

Настройка сборочной среды [ править ]

Для работы hasher требуется создать директорию, в которой будет строиться сборочная среда:

Рабочий каталог (в данном случае

/hasher) должен быть доступен на запись пользователю, запускающему сборку.

Кроме того, его нельзя располагать на файловой системе, которая смонтирована с опциями noexec или nodev — в таких условиях hasher не сможет создать корректное сборочное окружение.

Сборочное окружение можно создать явно:

Явное создание необязательно — при необходимости оно будет произведено при первой сборке пакета.

hasher берёт пакеты для установки из APT-источников. По умолчанию в сборочную среду копируется список источников, указанный в конфигурации APT хост-системы; также можно явно задать дополнительные репозитории, указав альтернативный файл конфигурации APT:

В таком файле конфигурации необходимо указать расположение файла с APT-источниками:

После создания сборочной среды (неявного, при сборке пакета, или явного, с помощью --initroot-only) параметр --apt-config больше не нужен.

Однако если необходимо создать сборочную среду, независимую по источникам от основной операционной системы (например, основная система настроена на sisyphus, а необходимо собрать пакет для p5), в вышеуказанный файл помимо строки с источником следует добавить следующую строку во избежание включения /etc/apt/sources.list.d/*.list :

Внимание! Замечено, что если apt подключен к репозиторию через прокси-сервер, то сборка пакета может завершаться с ошибкой «Connection reset by peer». Вероятно, это исправлено в apt-0.5.15lorg2-alt58. См. также APT_в_ALT_Linux/NginxAsCache#Известные проблемы.

Сборка программ в hasher [ править ]

Сборка происходит от обычного пользователя, добавленного с помощью hasher-useradd:

При удачной сборке полученные пакеты будут лежать в

/hasher/repo/<платформа>/RPMS.hasher/, в противном случае на stdout будет выведена информация об ошибках сборки.

Создаваемый hasher репозиторий является обычным APT-репозиторием и может быть использован в sources.list [3] . Также он будет использован при дальнейшей сборке пакетов (это поведение можно регулировать ключом --without-stuff).

Если вы держите сборочную среду в tmpfs (см. ниже), каталог

/hasher/repo, вероятно, не переживёт перезагрузку системы. Репозиторий можно переместить в постоянное место, указав в настроечном файле hasher .hasher/config параметр def_repo=постоянное_хранилище (или вызвав hasher с ключом --repo).

Сборочные зависимости [ править ]

Сборочные зависимости RPM делятся на два вида:

• необходимые для корректного создания src.rpm из spec-файла (содержащие определения RPM-макросов, используемых в spec-файле),
• все остальные (необходимые для непосредственной сборки).

Поскольку hasher собирает пакеты из src.rpm (не считая поддержки gear), то для сборки необходимо иметь в хост-системе установленные сборочные зависимости первого типа. Большинство таких зависимостей (но пока не все) содержатся в пакетах с названием rpm-build-*.

Поскольку сборка src.rpm либо завершается неудачно (при отсутствии сборочной зависимости первого типа), либо корректно, то собирать src.rpm-пакеты в хост системе можно с помощью --nodeps:

Сам hasher, в отличие от gear, не предъявляет никаких требований к разделению сборочных зависимостей на первый и второй тип. Однако для совместимости с gear и для улучшения документируемости spec-файла рекомендуется распределять их так:

• В поле BuildRequires(pre) помещать сборочные завимости, требуемые для сборки src.rpm,
• В поле BuildRequires — все остальные.

Обратите внимание: в поле BuildRequires(pre) нельзя использовать макросы.

Архитектура пакетов [ править ]

В связи с идиотизмомособенностями версии RPM, используемой в Sisyphus, rpmbuild (и, как следствие, hasher) на x86-системах могут собирать RPM-пакеты для совершенно разных архитектур: pentium3, pentium4, athlon и т.д.

Для отключения эвристик RPM по определению целевой архитектуры можно воспользоваться ключом --target или опцией конфигурации def_target.

или, более "интеллектуальный вариант":

Монтирование файловых систем внутри hasher [ править ]

Некоторым приложениям для сборки требуется смонтированная файловая система (например, /proc). hasher поддерживает монтирование дополнительных файловых систем в сборочную среду.

Монтирование происходит при одновременном выполнении следующих четырех условий:

• файловая система описана в файле /etc/hasher-priv/fstab , либо является одной из предопределённых: /proc, /dev/pts, /sys;
• в конфигурации hasher-priv ( /etc/hasher-priv/system ) ФС указана в опции allowed_mountpoints;
• файловая система указана в опции --mountpoints при запуске hasher, либо, что то же самое, в ключе known_mountpoints конфигурационного файла hasher (

• allowed_mountpoints=/proc в /etc/hasher-priv/system ;
• known_mountpoints=/proc в

Обязательно для использования java и иногда ghc [4] .

Для сборки в girar на git.alt достаточно сборочной зависимости на /proc.

Если вы используете hasher для интерактивной разработки/отладки, например, запускаете в нём gdb, вам может потребоваться смонтировать /proc на RW (а не на RO, как это сейчас по умолчанию). Для этого в /etc/hasher-priv/fstab нужно добавить примерно такую строку:

Использование нескольких сборочных окружений [ править ]

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

По умолчанию используется директория

Параллельная сборка [ править ]

По умолчанию hasher позволяет одному пользователю производить не больше одной сборки на данной системе в любой момент времени. Для преодоления этого ограничения используются subconfigs и дополнительные вспомогательные пользователи.

Детали применения такой конфигурации описаны на man-странице hsh(1) в описании ключа --number.

Сборка пакетов на tmpfs [ править ]

При наличии достаточного количества памяти на сборочной машине сборку пакетов рекомендуется производить на tmpfs — такая конфигурация заметно ускоряет сборку и бережёт жёсткие диски.

Можно взять уже смонтированный /tmp:

Создавать директорию /tmp/.private/$USER/hasher придётся после каждой перезагрузки (это можно сделать в файле

/.hasher/config, воспользовавшись тем, что это shell-скрипт). Указывать --repo придётся для каждой сборки (либо указать в .hasher/config параметр def_repo=постоянное_хранилище).

Начиная с 4.0, hasher-priv «из коробки» знает о директориях /tmp/.private/$USER , создаваемых pam_mktemp и поэтому дополнительной настройки не требует.

В altbug #16706 идёт обсуждение создания более удобного средства для сборки на tmpfs и имеется предварительная реализация.

Отключение проверок sisyphus_check [ править ]

По умолчанию hasher запускает утилиту sisyphus_check с полным набором тестов. sisyphus_check проверяет не только технические требования репозитория Sisyphus, но и организационные: сборочный хост, подпись PGP-ключом члена ALT Linux Team и т.д., так что в случае сборки пакета не для репозитория Sisyphus возникает необходимость отключить часть проверок.

Для отключения части или всех проверок используется ключ --no-sisyphus-check[=LIST] или, что эквивалентно, опция конфига no_sisyphus_check.

Без аргумента этот ключ отключает запуск sisyphus_check вообще:

С аргументом - списком отключаемых тестов - отключает только эти тесты:

Со списком тестов можно ознакомиться в подсказке самого sisyphus_check:

Более тонко запуск тестов можно настроить с помощью опций --no-sisyphus-check-in и --no-sisyphus-check-out, с описанием которых можно ознакомиться в man-странице hsh(1).

Ограничение ресурсов [ править ]

hasher позволяет ограничить ресурсы, выделяемые на сборку: CPU, память, общее время исполнения и другие. Ограничения указываются в конфигурационном файле hasher-priv.

Полный список ограничиваемых ресурсов можно найти в man-странице hasher-priv.conf(5).

Отладка в сборочном chroot [ править ]

Для отладки сборки иногда полезно запустить shell в сборочном chroot. Для этого используется утилита hsh-shell(1):

Можно запустить программу и с правами псевдо-root:

Для контроля за содержимым сборочного chroot'а используются опции hsh: --cleanup-only, --eager-cleanup, --lazy-cleanup и соответствующие настройки вроде lazy_cleanup=1 в

Для запуска произвольных программ в сборочном чруте существует более низкоуровневая утилита hsh-run(1).

Использование buildreq в hasher [ править ]

Начинаем и обламываем сборку пакета в hasher:

После этого в спеке появляется новая строка BuildRequires , сопровождаемая комментарием вида # Automatically added by buildreq . (если такая строка с комментарием уже была, она заменяется).

Из хост-системы получившийся спек доступен тут:

Примечание. Если сборка делалась автономно, buildreq будет сообщать об ошибках отсутствия файлов, и понадобится скопировать в chroot hasher'a файлы: спек в

/hasher/chroot/usr/src/RPM/SPECS/ и файлы-источники в

Пересборка пакета без пересоздания всего chroot [ править ]

Даже в tmpfs развёртывание всей сборочной среды и зависимостей идёт небыстро.

Для того, чтобы собирать один и тот же пакет до тех пор, пока он не соберётся, нужно попросить hasher не разворачивать заново всю сборочницу, либо работать в самой сборочнице.

Пакет не собрался. Воспользуемся hsh-shell , предварительно установив любимый текстовый редактор, шелл, конфиги для них и прочие инструменты разработчика. Не забудем, что в дереве каталогов hasher есть каталог

/hasher/chroot/.in , в которой может писать сам пользователь (а не его двойники, пользователь_a и пользователь_b).

zsh ругается на то, что системные файлы не принадлежат root, если вас это смущает, отключите проверку так:

Отсутствующие сборочные зависимости можно доставлять с помощью hsh-install (выйдя из чрута).

ВАЖНО: по окончании работы ( rpm -ba выполнился успешно) не забудьте выполнить buildreq , rpm -bs и забрать .src.rpm из

/hasher/chroot/usr/src/RPM/SRPMS (или спек из

Если вы используете gear и предпочитаете вести разработку (редактировать спек, править код и т. п.) в базовой системе, вместо hsh можно использовать hsh-rebuild -- программу, работающую с уже сформированным сборочным окружением.

Первоначальная сборка (даже если прошла успешно, окружение не удаляется):

ВАЖНО: по окончании работы не забудьте выполнить buildreq и забрать спек: