Часто во время сборки пакетов по зависимостям предлагается установить очень много «лишнего» ПО. Это не всегда бывает удобно: не хочется «мусорить» в уже рабочей системе или вообще нежелательно в ней иметь некоторые средства (например, средства разработки на сервере). Часто банальной причиной является нежелание где-то искать это ПО – этот процесс утомляет, особенно если репозитарий пакетов для дистрибутива представлен в виде нескольких дисков, то всё сводится к «жонглированию» дисками...
Поэтому в дистрибутивы ALT Linux попадают только пакеты, заботливой рукой мантейнера проведённые через технологию hasher. Эта технология позволяет собирать пакеты внутри «чистого» окружения (chroot), которое создаётся из числа пакетов, входящих в состав описанных на пользовательской машине репозитариев. Т.е. в чистом окружении устанавливаются все необходимые для сборки данного пакеты (сборочная среда), затем в этом окружении и происходит сборка. В реальную систему пакеты при этом не ставятся. Таким образом, на входе hasher получает src.rpm пакет, а на выходе выдаёт уже собранные (только из данного src.rpm) пакеты, которые мы уже можем использовать в наших репозитариях для установки на рабочие системы.
За технологию hasher отвечают два пакета: hasher и hasher-priv, для работы последнего также нужен пакет sisyphus_check.
Внутри пакета hasher содержится краткая, но ёмкая документация: README, QUICKSTART и FAQ файлы, а также man-страницы, правда, они на английском языке, хотя разработчики программы вполне русскоговорящие. Этой документации, в принципе, хватает, чтобы начать работать c hasher, а в FAQ рассмотрены некоторые проблемы, которые могут возникать в работе. Но рассмотрим дополнительно некоторые аспекты работы с hasher.
На данном этапе все просто. От пользователя root выполняем:
# apt-get install hasher
Затем необходимо подготовить hasher – объявить, что какой пользователь имеет право пользоваться услугами hasher:
# hasher-useradd koal
Теперь этому пользователю нужно заново войти в систему (причём предварительно полностью завершив сеанс, запуск нового терминального сеанса, например, в konsole, не приведёт к нужному эффекту).
Необходимо создать каталог, в котором будет строиться сборочная среда:
$ mkdir HASHER
Рабочий каталог hasher должен быть доступен на запись пользователю, запускающему сборку. Кроме того, его не следует располагать на файловой системе, которая смонтирована с опциями noexec или nodev.
Создаем рабочую сборочную среду:
$ hsh HASHER --init
Hasher использует для получения пакетов APT-репозитории. Для ускорения сборки имеет смысл держать репозитории локально (file: или copy: источники в sources.list) или в быстрой локальной сети.
Сейчас работа должна происходить от обычного пользователя (но добавленного с помощью hasher-useradd).
Выполняем сборку:
$ hsh HASHER freetype-2.1.9-alt2.src.rpm
здесь
При удачной сборке полученные пакеты будут лежать в HASHER/repo/<платформа>/RPMS.hasher/. А если произошла ошибка, то информация о ней будет выведена на экран. Например, это информация о том, что какие-то пакеты, необходимые для сборки данного, не были обнаружены в доступных репозитариях.
Кстати, указанный выше репозитарий (HASHER/repo/<платформа>/RPMS.hasher/) можно использовать для установки, сразу после описания его в /etc/apt/sources.list.
damir@ просуммировал так:
Билдреки делятся на два типа – те которые нужны для _сборки_ src.rpm,
и те, которые нужны для сборки .rpm.
Первые – это всевозможные rpm-build-* и *-devel, которые содержат
файлы в /etc/rpm/macros.d (то есть определяют новые макросы).
Посмотреть их список в системе можно например через rpm -qf /etc/rpm/macros.d/*
От значения этих макросов часто зависят остальные билдреки например.
Из одного и того же спека можно получить разные src.rpm, если собирать
их на разных системах, с разными «билдреками первого типа». Например,
так у нас сделан Питон, а также firefox и все его хозяйство.
Такие билдреки должны быть удовлетворены _до_ передачи пакета в хэшер.
Обычно если rpm ругается на неопределенные макросы и не запаковывает
спек. Так что их ставить все равно придется.
2Team: Может сделать полиси, по которым файлы в /etc/rpm/macros.d
могут находиться только в пакетах типа rpm-build-*?
Остальные билдреки относятся к сборке rpm из src.rpm, и могут быть
легко отключены через --nodeps
rpm -bs --nodeps foo.spec
(описал Женя Остапец сиречь eostapets@)
Если в системе много оперативной памяти, то иногда бывает выгодно держать рабочий каталог hasher-а на tmpfs. Это значительно ускоряет развертывание чрута и установку пакетов, а также их сборку.
В принципе можно просто создать каталог на tmpfs и запускать hasher с этим каталогом в качестве рабочего.
Но в каталоге хэшера есть некоторые части (repo и chroot-cache), которые занимают достаточно большое место, и совершенно не обязаны находиться в tmpfs.
Можно создавать симлинки на cache и repo в каталоге на tmpfs вручную или с помощью нижеприведенного скрипта by damir@:
Здесь /tmp – каталог куда смонтирована файловая система tmpfs (если у вас она смонтирована куда-нибудь в другое место – замените на нужное в скрипте).
/hasher – это workdir для hasher-а не на tmpfs, в котором уже должны быть каталоги repo и cache. Все собранные hasher-ом пакеты окажутся там, и не будут потеряны при перезагрузке.
Однако, как показала практика, на деле всё происходит не так гладко – при последующей сборке других пакетов может выдаваться ошибка вида:
Дело в том, что на платформах i686 (athlon, Kx, pentium4) сборка автоматически происходит для неё. Вот что сказал Алексей Фролов в community@altlinux.ru:
Тогда возможный путь решения проблемы находится в man hsh в виде опции --target. То есть сборку можно осуществлять следующим образом:
$ hsh --target=i586 HASHER freetype-2.1.9-alt2.src.rpm
или добавить в файл ~/.hasher/config строчку:
def_target=i586
Но приведённая выше ошибка выдавалась все равно. Оказалось, что когда-то давно пакет freetype2 версии 2.1.9 был уже собран под платформу athlon и положен в репозитарий для данной платформы. И hasher пытался использовать пакеты именно этой сборки. Поэтому я удалил из athlon-репозитария все пакеты, касающиеся freetype-2.1.9: freetype2, freetype2-demos, freetype2-devel. После этого сборка прошла успешно.
Следующая проблема может возникнуть при самосборных src.rpm: hasher будет ругаться на неверный PACKAGER у собираемого пакета:
Тут всё дело в том, что hasher предназначается для тестирования сборки пакетов перед отправкой их в Sisyphus, поэтому помимо самой сборки происходит проверка на правильность заполнения служебной информации об rpm-пакете. В случае с Sisyphus, пакеты в нём могут размещать только члены ALT Linux Team, соответственно, в поле PACKAGER должен быть указан один их них. Это проверяется утилитой sisyphus_check по наличию altlinux.com|net|org|ru после "@". man hsh говорит, что данную проверку можно отключить, указав опцию --no-sisyphus-check[=LIST], где LIST – список пропускаемых тестов. О тестах, которые может пропустить sisyphus_cheсk, логичнее спросить у него самого:
$ sisyphus_check --help
Итак, пробуем отключить тест на PACKAGER, а заодно и проверку GPG-подписи:
$ hsh --target=i586 --no-sisyphus-check=packager,gpg HASHER some-packet.src.rpm
Теперь работает...
Для сборки пакетов java должен быть доступен /proc внутри hasher.
Подробнее см. /AltLinux/Policy/Java/JavaPackagingFAQ#h8063–15
Спасибо за помощь в «разборках» с hasher Алексею Фролову aka raorn.