Сборка RPM-пакетов
Статья составлена с учётом наставлений Hihin Ruslan (ALT Linux Team)
Информация
Для понимания сразу оговорюсь
$ - выполнение команды от обычного пользователя
# - выполнения команды от пользователя root
Клонирование репозитория и начало сборки
Для начала создаём каталог (если не создан) где мы будем хранить клон репозиториев, пускай это будет build_packages
$ mkdir ~/build_packagesДалее выполняем вход в каталог и выполняем клонирование.
$ cd build_packages/
$ git clone https://gitlab.gnome.org/subpop/damask.gitВ случае использования автоматического создания spec-файла, клонирование репозитория будет сделано (или не сделано) при создании spec-файла. см. раздел (Spec)
После чего мы заходим в клонированный репозиторий и создаём директорию .gear где размещаем файл правил (rules) и файл правил сборки (spec)
$ cd damask/
$ mkdir .gear
$ cd .gear/
$ touch rules damask.specДалее пишем наш rules и damask.spec
После чего выходим в каталог выше и добавляем файлы к репозиторию, чтобы при сборке они были видны
$ cd ..
$ git add .gear/rules .gear/damask.specДалее запускаем сборку
$ gear-hsh --no-sisyphus-check=packager,gpg --commit -vИнформация
--no-sisyphus-check=packager,gpg - означает отключение проверки Сизиф только в части того кто упаковывает и его ключа.
Vendoring - "вендоринг", распространение
Некоторые пакеты (к примеру RUST, GO, Node или Java) могут требовать дополнительных модулей, которые скачиваются во время сборки, однако при сборке доступ к интернету запрещён по умолчанию.
Для решения данной проблемы необходимо дать доступ хешеру к сети Интернет и выкачать недостающие модули зайдя во внутрь хешера.
Информация
ВАЖНО Прежде чем зайти в хешер, нужно его собрать. Хешер собирается командой сборки. То есть если туда зайти сразу, он будет пустой, если запустить команду сборки пакета, он соберётся и после входа во внутрь хешера он будет не пустой. Если запустить сборку другого пакета, внутри хешера будет другой пакет.
Для этого сначала посмотрим наш сервер DNS
# cat /etc/resolv.confДалее пробрасываем его в хешер, это нужно для того, чтобы хешер смог увидеть Интернет.
$ hsh-shell --rooter
echo nameserver 8.8.8.8 >> /etc/resolv.conf
exitГде 8.8.8.8 = вашему DNS, который вы увидели командой выше.
Для удобства добавляем в наш хешер файловый менеджер MC, также в примере ниже указан принцип как добавить во внутрь хешера нужные пакеты.
$ hsh-install mcЗаходим в наш хешер с доступом в сеть Интернет.
$ share_ipc=yes share_network=yes hsh-shell --mount=/dev/pts,/procПосле успешного входа, как вариант, открываем MC и переходим в каталог пакета
/usr/src/RPM/BUILD/НАШ_ПАКЕТВ данном каталоге будут лежать файлы отвечающие (назовём это так) за дополнительные модули, где мы выполняем команду на скачивание этих модулей
В случае с:
Rust
Это будет файл Cargo.toml, поэтому нужно выполнить команду
cargo vendorТем самым будет создан каталог vendor с модулями
Также в случае с Rust необходимо прописать файл конфига, чтобы сборщик видел откуда брать модули.
Создаём каталог .cargo и добавляем файл config.toml где будут прописаны связи, чтобы при сборке билдер понимал, что ему нужно брать файлы не с сети Интернет, а с каталога vendor.
$ mkdir .cargo
$ cd .cargo
$ touch config.tomlИнформация по заполнению config.toml указана в терминале во время выполнения команды cargo vendor
Обычно это
[source.crates-io]
replace-with = "vendored-sources"
[source.vendored-sources]
directory = "vendor"Далее добавляем файл config.toml в git
$ git add .cargo/config.tomlGo
Выполняем команду
go mod vendorБольше никаких телодвижений не требуется
Node
Выполняем команду
yarn installТут стоит обратить внимание, что перед использованием yarn необходимо установить его во внутрь хешера
После выполнения будет создан каталог с модулями node_modules
Java
Рекомендую воспользоваться инструкцией с
Информация
Обращаю внимание, что ниже будет описана работа сборки вне хешера, после скачивания доп модулей.
После того, как были скачаны дополнительные модули их необходимо переместить хешера в наш каталог с репозиторием, к примеру
От сюда
$ ~/hasher/chroot/usr/scr/RPM/BUILD/НАШ_ПАКЕТ/
Сюда
$ ~/build_packages/НАШ_ПАКЕТ
То есть на выходе будет путь
$ ~/build_packages/НАШ_ПАКЕТ/vendor
в случае с node
$ ~/build_packages/НАШ_ПАКЕТ/node_modulesИнформация
Обращаю внимание, что далее приводится пример по добавлению каталога с доп модулями в git, без создания дополнительного vendor.tar Этого вполне достаточно, хотя иногда бывают ситуации когда нужен отдельный tar, но обычно добавления в git, как уже сказал - достаточно.
Для обработки данных модулей нам необходимо добавить в git непосредственно весь каталог с модулями.
git add --all -f КАТАЛОГ_С_МОДУЛЯМИНа практике возможна ситуация, что конструкция git add . не сработает, поэтому используется конструкция выше.
Также стоит обратить внимание, что для Rust необходимо прописать config.toml как указано выше.
Далее просто запускаем сборку
$ gear-hsh --no-sisyphus-check=packager,gpg --commit -vСборка внутри хешера
Сборка внутри хешера осуществятся по средствам rpm
После того, как хешер собран и осуществлён вход можно приступить к сборке и экспериментам внутри хешера.
Для этого необходимо перейти в каталог со spec файлом и просто запустить сборку
cd /usr/src/RPM/SPECS/
rpm -ba CUSTOM_SPEC.specСборка вне хешера
Сборка вне хешера (в самой системе) осуществляется по средствам rpm
До начала сборки необходимо подготовить рабочее пространство (дерево каталогов) для сборки пакетов.
Это можно сделать с помощью команды
$ rpmdev-setuptreeЛибо в ручную с помощью mkdir
Каталог rpmbuild создается в домашней папке пользователя.
cd $HOME
mkdir rpmbuildВ самом же каталоге создаются подкаталоги:
- BUILD - каталог сборки
- RPMS - каталог выходных/собранных пакетов rpm
- SOURCES - каталог источника (архивы, патчи, исходный код)
- SPECS - каталог spec файлов
- SRPMS - каталог пакетов исходников src.rpm
Сборка пакета осуществляется с помощью команды
$ rpm -ba CUSTOM_SPEC.specПомимо этого, не забываем настроить файл .rpmmacros расположенные в домашней папке пользователя.
Александр Шамараев
Давид Султаниязов
Антон Политов
Олег Щавелев