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

Материал из ALT Linux Wiki
(Внос черновика-описания сборки пакета для ALT Linux с помощью Gear/Hasher.)
 
(не показано 18 промежуточных версий 13 участников)
Строка 1: Строка 1:
[[Категория:HOWTO]]
[[Категория:Руководства]]
{{Stub}}
{{Stub}}
{{Note|На данной вики есть еще статья [[Сборка пакетов start]] из проекта [[Developer_start|Начинающему разработчику]]}}
{{Note|На данной вики ещё есть статья [[Сборка пакетов (etersoft-build-utils)]], предлагающая минимальный порог вхождения в процесс сборки.}}


Данное руководство покажет, как правильно собрать пакет RPM в [[Sisyphus]] с нуля в инфраструктуре [[Gear]] и [[git.alt]], имея только исходный код пакета, и [[Join|права мейнтейнера]] на '''git.alt'''. В качестве примера опакетим [http://sourceforge.net/projects/kchildlock/ KChildlock], чтобы закрыть запрос на сборку в багзилле: [https://bugzilla.altlinux.org/25111 https://bugzilla.altlinux.org/25796].
Данное руководство покажет, как правильно собрать пакет RPM в [[Sisyphus]] с нуля в инфраструктуре [[Gear]] и [[git.alt]], имея только исходный код пакета, и [[Join|права мейнтейнера]] на '''git.alt'''. В качестве примера опакетим [http://sourceforge.net/projects/kchildlock/ KChildlock], чтобы закрыть запрос на сборку в багзилле: [https://bugzilla.altlinux.org/25796 https://bugzilla.altlinux.org/25796].


== Введение ==
== Введение ==
Строка 11: Строка 11:
# У вас установлен дистрибутив ALT Linux;
# У вас установлен дистрибутив ALT Linux;
# Есть желание собрать пакет правильно, а не для единичного случая;
# Есть желание собрать пакет правильно, а не для единичного случая;
# Вы носите гордое звание «мейнтейнер ALT Linux Team», что подразумевает наличие электронных ключей и доступа к инфраструктуре [[git.alt]]
# Вы носите гордое звание [[Руководство_начинающего_мейнтейнера_ALT_Linux_Team|«мейнтейнер ALT Linux Team»]], что подразумевает наличие электронных ключей и доступа к инфраструктуре [[git.alt]]


Третий пункт необязателен для новичков, которые просто хотят собрать пакет правильно для себя.
Третий пункт необязателен для новичков, которые просто хотят собрать пакет правильно для себя.
Строка 21: Строка 21:
* Собранный двоичный пакет (имеет расширение вида ''<архитектура>.rpm''). В качестве архитектуры может быть i586, x86_64 или noarch. Такие пакеты можно устанавливать командой <pre>rpm -Uvh package...rpm</pre>
* Собранный двоичный пакет (имеет расширение вида ''<архитектура>.rpm''). В качестве архитектуры может быть i586, x86_64 или noarch. Такие пакеты можно устанавливать командой <pre>rpm -Uvh package...rpm</pre>


Подробную информацию по структуре RPM и сборке с помощью команды rpm можно найти в [http://www.rpm.org/max-rpm/ Maximum RPM].
Подробную информацию по структуре RPM и сборке с помощью команды rpm можно найти в [http://ftp.rpm.org/max-rpm/ Maximum RPM].


Однако для сборки через rpmbuild возникают очевидные сложности:
Однако для сборки через rpmbuild возникают очевидные сложности:
Строка 46: Строка 46:
* Доступ к [[Branches|репозиторию пакетов]]
* Доступ к [[Branches|репозиторию пакетов]]


Для этого [[Управление пакетами|настройте репозитории]] и установите пакеты build-environment и gear:
Для этого [[Управление пакетами|настройте репозитории]] и установите пакеты:


  apt-get install build-environment gear
  apt-get install rpm-build hasher gear


Будут установлены с зависимостями все необходимые пакеты для опакечивания и сборки
Будут установлены с зависимостями все необходимые пакеты для опакечивания и сборки.


== Настройка среды ==
== Настройка среды ==


=== Окружение Git ===
=== Окружение Git ===
Для идентификации Вашего ключа, Вашего имени, адреса электронной почты введите:


  git config --global user.name 'Andrey Cherepanov'
  git config --global user.name 'Andrey Cherepanov'
  git config --global user.email 'cas@altlinux.org'
  git config --global user.email 'cas@altlinux.org'
  git config --global user.signingkey 'A9EBF131'
  git config --global user.signingkey 'A9EBF131'
или
gpg --gen-key


Измените в зависимости от ваших параметров. Третья команда задаёт идентификатор вашего GPG-ключа для подписи:
Измените в зависимости от ваших параметров. Третья команда задаёт идентификатор вашего GPG-ключа для подписи:
Строка 84: Строка 89:
  [cas@cas ~]$ LANG=C gpg --fingerprint A9EBF131 | grep 'fingerprint =' | tr -d ' ' | cut -d= -f2
  [cas@cas ~]$ LANG=C gpg --fingerprint A9EBF131 | grep 'fingerprint =' | tr -d ' ' | cut -d= -f2
  A424A3962331FDD2748BC8B34863C0F4A9EBF131
  A424A3962331FDD2748BC8B34863C0F4A9EBF131
или
[cas@cas ~]$ gpg --fingerprint A9EBF131 | sed -n '/.*=/{s/.*=/%_gpg_name\t/;s/ //gp}'
%_gpg_name A424A3962331FDD2748BC8B34863C0F4A9EBF131


== Окружение Hasher ==
== Окружение Hasher ==
Строка 109: Строка 117:
  mount=/dev/pts,/proc
  mount=/dev/pts,/proc


Соответственно, USER должен быть такой же, как заведён в ''hasher-useradd'', target — указывать на архитектуру собираемый пакетов.
Соответственно, USER должен быть такой же, как заведён в ''hasher-useradd'', target — указывать на архитектуру собираемых пакетов.


== Подготовка репозитория Git ==
== Подготовка репозитория Git ==


=== Создание репозитория ===
Репозиторий Git создать очень просто. Для этого создадим каталог (имена пакетов лучше указывать в нижнем регистре, поэтому наш пакет для проекта будет называться '''kchildlock'''), перейдём в него и запустим '''git init''':
Репозиторий Git создать очень просто. Для этого создадим каталог (имена пакетов лучше указывать в нижнем регистре, поэтому наш пакет для проекта будет называться kchildlock), перейдём в него и запустим git init:
 
    mkdir kchildlock
    cd kchildlock
    git init .
 
=== Создание веток ===


Совсем необязательно, но удобно, когда оригинальный программный код расположен в отдельной ветке репозитория. Тогда код, в который вносятся изменения, файлы необходимые для сборки RPM пакета располагаются в своих, отдельных ветках. Если в этом нет нужды, продолжение этого раздела можно пропустить.
mkdir kchildlock
 
cd kchildlock
Например, можно сделать вот такие ветки:
git init .
* master - здесь будут находится служебные файлы, используемые при сборке RPM пакета: Spec файлы, файлы Gear (.gear/, и прочее). Программный код может быть, а может и не быть в этой ветке. По выбору собирающего пакет.
* upstream - оригинальный, авторский, распакованный программный код, как он был предоставлен. Этот код будет хранится в этой ветке неизменным.
* devel - ветка, в которую будет скопирован авторский код. Если потребуется вносить изменения в программу, то изменения будут внесены именно в этой ветке.
 
Создайте необходимые ветки и заготовки файлов (команды выполняются в каталоге с созданным ранее репозиторием):
    mkdir .gear
    touch .gear/rules
    touch kchildlock.spec
    git add .gear/rules kchildlock.spec
    git commit -a -m "Initial."
    git branch upstream
    git branch devel
 
Можно проверить, что получилось:
    git branch
    git status
GIT сообщает, что текущая(активная) ветка 'master' (помечена '*' в выводе первой команды), что в отслеживаемых файлах нет изменений (вторая команда, там же - тоже указано имя текущей ветки).


== Написание .gear/rules ==
== Написание .gear/rules ==
Забегая вперёд, создайте правило для Gear.
    echo "tar.gz: targetTag:kchildlock" > .gear/rules
Здесь 'targetTag' - некое, пока ещё "волшебное", имя. Это имя будет символизировать какой код, из какой ветки Вы хотите собрать и упаковать в RPM. Есть рекомендации составлять это имя из версии программы и номера сборки. Например: 0.0.1-alt4. Т.е. 0.0.1 - версия программы, alt4 - четвёртая сборка этой версии для ALT Linux. Я здесь выбираю это имя равным 'targetTag'.
'kchildlock' - это имя каталога, в котором будет находиться программный код. Оно соответствует имени собираемого пакета. Код из этого каталога будет собран и упакован в пакеты.


== Импорт исходного кода ==
== Импорт исходного кода ==
=== Простой способ ===
Есть разные способы. Простейший: скопировать программный код в один из каталогов в репозитории.
Для этого выполните:
    git checkout upstream
    mkdir -p kchildlock
И любыми удобными средствами распакуйте, скопируйте исходный код программы в каталог 'kchildlock'.
Когда код скопирован, выполните:
    git add kchildlock
    git commit -a -m "Original source code is imported."
=== Импорт из src.rpm ===


== Написание спека ==
== Написание спека ==
В Spec файле потребуется указать группу, к которой нужно отнести собираемый пакет. Список групп в файле '/usr/lib/rpm/GROUPS'.
=== Поиск зависимостей ===
Поиск - занятие творческое. Панацеи нет. Сначала нужно посмотреть, что пишут авторы у себя на сайте, в файлах, приложенных к исходному коду. Это сформирует примерный список нужного.
Теперь можно использовать поиск в репозитории дистрибутива. Это команды:
    apt-cache search искомое-сочетание1 искомое-сочетание2
    apt-cache show имя-существующего-пакета
Найденные зависимости должны быть внесены в Spec файл.
После этого можно пытаться собрать пакет, переходить к следующим разделам этой статьи. Но! Часто бывает - не все зависимости были найдены сборщиком пакета. Тогда, позже надо будет вернуться к редактированию Spec файла. При сборке пакета, в отчётах о ошибках будут упоминаться имена конкретных недостающих файлов. Нужно искать пакеты в которых есть эти файлы. Решать какие из этих пакетов перечислить в Spec файле.
Один из способов поиска - творчески применять выше перечисленные утилиты apt-*. Один из более эффективных способов - смотреть в индексных файлах 'contents_index' репозитория. В этих файлах на отдельных строках приведено соответствие полного имени файла из пакета и имени этого пакета.
Пример расположения этих файлов:
        repo-address/repo-name-architecture/base/contents_index
        /altair/ALT/Sisyphus/noarch/base/contents_index
        /altair/ALT/p6/noarch/base/contents_index
'repo-address', '/altair/ALT/*/' и т.п. это адреса репозитория, описанные в файле '/etc/***/apt.conf'.
'repo-name-architecture', 'noarch' - архитектура пакетов в репозитории.
'base' - имя каталога с искомым файлом.
Репозиториев, обычно, несколько. Индексных файлов будет несколько. Некоторые из файлов размером в сотни Мб.
Искать удобно так:
* сложить все файлы в один каталог под именами вроде contents_index_имя-архитектура-репозитория
* выполнять в этом каталоге команду:
    grep -r искомая-часть-имени .
/* Есть заготовка скрипта для вытаскивания файлов. */
А иногда в дистрибутивах (в репозиториях) бывают доступны специальные, готовые к использованию утилиты для поиска соответствий короткого имени файла и имени пакета. Например, утилита 'apt-file'.
Если зависимость всё равно не находится, то далее можно разбирать скрипты конфигурации и т.п. Смотреть, что именно ищется конфигураторами кода, пытаться понять, что именно в своём дистрибутиве соответствует найденному в конфигураторах, прорабатывать это.
Возможно, что проще, иногда правильнее, собрать из оригинального кода дополнительные, отдельные пакеты с недостающими зависимостями. Но не всегда. Панацеи нет.
Есть и аварийный выход: взять зависимость в виде готового RPM пакета из другого дистрибутива. Например, скопировать из Fedora-Project и т.п. Возможно взять исходный код нужной версии собираемого пакета (*.src.rpm файлы) неавторский, а проработанный кем-то для Fedora-Project. И собирать уже его.
=== Секция инсталляции ===
При использовании утилиты 'install' можно не указывать конечного владельца и группу для инсталлируемого файла. Т.е. вместо
        install -m755 -o root -g root targetFile %{buildroot}%{_bindir}
может быть использовано
        install -m755 targetFile %{buildroot}%{_bindir}
=== О макросах ===
Если нужно узнать какие макросы есть в системе, можно заглянуть в файлы:
    /etc/skel/.rpmmacros
    /etc/skel.ru_RU.CP1251/.rpmmacros
    /etc/skel.ru_RU.KOI8-R/.rpmmacros
    /home/${USER}/.rpmmacros
    /usr/lib/rpm/*
    /etc/rpm/*
Во что разворачивается макрос '%make_install' можно увидеть так:
    rpm --eval %make_install
Система сборки пакета раскрывает макросы в Spec файле, даже если они находятся внутри комментария. Если нужно "выключить" макрос, то делается это аналогично выключению спец.символов в других системах - удвоением, повторением спец.знака '%':
    # экранированный макрос %%configure
=== Конкретный пример Spec файла ===
/* Может быть на примере "Hello world.", вместо 'kchildlock' ???? */


== Сборка в Hasher ==
== Сборка в Hasher ==
В процессе сборки пакета, на диске будет существовать два важных, но разных каталога. 1) - каталог с GIT репозиторием, 2) - каталог с песочницей Hasher, в которой будут работать утилиты, собирающие пакет.
=== Немного ещё слов о GIT ===
GIT репозиторий хранит в себе историю изменения кода. Каждый коммит в репозиторий имеет свой идентификатор - SHA1 хэш, соответствует внесению каких-либо изменений. Можно сказать: каждый коммит соответствует какому-либо состоянию кода в той или иной ветке. Для сборки можно выбрать любое конкретное состояние кода, из любой ветки, указав сборочным утилитам нужный идентификатор коммита. Т.е. можно собирать пакет из кода какой-либо неактуальной и старой версии, всё ещё хранимой как история в репозитории. Или из кода хранимого в ветке, соседней по отношению к содержащей Spec файл.
=== Подготовка репозитория ===
Сборка будет осуществляться из ветки репозитория, содержащей Spec файл, Gear правила - т.е. из 'master'. Переключитесь на эту ветку:
    git checkout master
Перед сборкой нужно определить какое именно сотояние кода, из истории в репозитории, нужно собирать - нужно выбрать какой-либо идентификатор коммита. Смотрите вывод комманды:
    git log
Иногда в разборе истории помощь могут оказать разнообразные визуализаторы истории. Например, утилита gitk.
Например, пусть нужный коммит имеет SHA1 хеш равный '0123456789abcdef01234567890abcdef0123456'. Пометьте этот коммит тегом 'targetTag', обновите теги Gear, внесите сделанные изменения в репозиторий:
    git tag -u A9EBF131 targetTag 0123456789abcdef01234567890abcdef0123456
    gear-update-tag --all
    git commit -a -m "GIT and Gear tags updated."
Здесь идентификатор A9EBF131 надо заменить на идентификатор Вашего PGP ключа.
Свяжите текущее состояние ветки 'master' c выбранным для сборки состоянием кода (нужны имя ветки и хеш ранее выбранного коммита):
    git merge -s ours upstream 0123456789abcdef01234567890abcdef0123456
Теперь, при запуске сборки, система будет собирать и упаковывать состояние кода, помеченное тегом 'targetTag'. См. ранее о правилах Gear.
=== Подготовка песочницы ===
Можно собирать пакет в каталоге-песочнице, создаваемом по умолчанию. Удобнее иметь несколько разных каталогов - несколько разных песочниц. Под разные архитектуры, под разные пакеты и разные версии...
Пускай путь к каталогу с песочницей будет '/pathToSandbox', собирать пакет требуется для x86_64 архитектуры. Структура каталогов, файлы в песочнице будут следующими:
  /pathToSandbox
  |-hasher (файлы apt.conf, compile, priorities, sources.list)
  |---repo
  |-----SRPMS.hasher
  |-----x86_64
  |-------RPMS.hasher
  |-tmp
Содержимое файлов см. ниже в приложении.
Если в каталоги вида '/pathToSandbox/repo/x86_64/RPMS.hasher' скопировать какие-либо RPM пакеты, сборочные утилиты могут использовать эти пакеты. Например, в этот каталог можно добавлять пакеты-зависимости отсутствующие в доступных репозиториях. Эти пакеты зависимости будут использованы при сборке (установлены внутри песочницы). Есть алгоритм выбора пакетов-зависимостей из репозиториев. Обычно (Всегда? А apt.*?) выбирается пакет с наибольшей версией.
=== Сборка ===
Конструирование песочницы занимает ощутимое временя. Для экономии времени можно использовать такую стратегию: сгенерировать песочницу один раз, при первой попытке сборки; в последующих попытках использовать уже готовую песочницу; GIT репозиторий не засорять пробными версиями Spec файла и т.п., используя параметр '--commit'.
Команды сборки выполняются в корневом каталоге GIT репозитория, активная ветка GIT репозитория - содержащая Spec файл и Gear правила.
Первичные команды для создания песочницы и сборки:
    hsh --cleanup-only /pathToSandbox
    gear --verbose --commit --hasher -- hsh --verbose --lazy-cleanup --mountpoints=/proc --apt-config="/pathToSandbox/apt.conf" /pathToSandbox
Последующие попытки сборки выполняйте командой:
    gear --verbose --commit --hasher -- hsh-rebuild --verbose --mountpoints=/proc /pathToSandbox
Полную очистку через 'hsh --cleanup-only' делать совершенно необязательно. Более точные команды см. в приложении - внизу страницы, "Файл compile для песочницы."
Если необходимо получать логи сборки в текстовых файлах, то используйте команду:
    timestamp=$( date '+%Y-%m-%d-%H%M-%S' ) ; gear ... -- hsh ... 2>./error-${timestamp}.log 1>./build-${timestamp}.log ; unset timestamp
Многоточия надо заменить на необходимое, см. выше. (Неужели нет иного способа логгировать в файл или иную сущность, удобную для поиска в логе?)
Обратите внимание, что здесь прямо указан файл конфигурации apt.conf, несовпадающий с указанным в конфигурационном файле Hasher. Это может быть удобно, в случае многих песочниц.
При успешном окончании сборки будут выведены, в числе других, сообщения о том, куда и какие созданные RPM пакеты были скопированы.
=== Исследование результатов сборки ===
Если сборка неудачна, может потребоваться исследовать файлы и т.п. внутри песочницы. Для входа в песочницу используйте команды:
    hsh-shell /pathToSandbox
    hsh-shell --rooter /pathToSandbox
Вторая команда позволяет получить root привилегии внутри песочницы.
Без дополнительных телодвижений нельзя одновременно войти в песочницу и осуществлять какие-то ещё операции Hasher. Однако, запущенное "параллельное" действие не прерывается, а ждёт окончания других операций.
Список инструментов внутри песочницы краток. Имена пакетов с недостающими необходимыми инструментами можно добавить как зависимости сборки в Spec файле - пакеты будут установлены в песочницу. Так же, можно использовать команду 'hsh-install' для доустановки пакетов вручную, находясь снаружи песочницы.
Для корректной работы некоторых программ в песочнице необходимо иметь внутри песочницы смонтированными некоторые файловые системы. Например, /proc для Java инструментов.
Сборочные утилиты производят ряд проверок файлов, получаемых при сборке, упаковываемых в пакет. При необходимости для исследований, некоторые проверки можно отключить. Одно из средств выключения - макросы в Spec файле:
    %set_verify_elf_method no
Ещё - можно заглянуть в файлы '/usr/lib/rpm/noarch-linux/macros', '/usr/lib/rpm/brp.d/064-verify_elf.brp', '/usr/lib/rpm/verify-elf'.
Можно отключать проверки через аргументы в коммандной строке для Hasher. Например, вот такой аргумент '--no-sisyphus-check=bindir,subdirs,summary'.


== Отправка в git.alt ==
== Отправка в git.alt ==
== Приложения ==
=== Файл apt.conf для песочницы ===
    Dir::Etc::main "/dev/null";
    Dir::Etc::parts "/var/empty";
    Dir::Etc::sourcelist "/pathToSandbox/sources.list";
    Dir::Etc::pkgpriorities "/pathToSandbox/priorities";
    Dir::Etc::sourceparts "/var/empty";
    APT::Cache-Limit "67108864";
=== Файл priorities для песочницы ===
    Important:
        basesystem
        altlinux-release-sisyphus
    Required:
        apt
=== Файл sources.list для песочницы ===
    rpm file:/altair/ALT/Sisyphus x86_64 classic
    rpm file:/altair/ALT/Sisyphus noarch classic
=== Файл compile для песочницы ===
Файл 'compile' является скриптом-обёрткой для запуска описанных в статье команд сборки (в т.ч. с указанием архитектуры и т.д.). В каталоге с GIT репозиторием можно создать символическую ссылку на такой файл. Можно создать разноимённые ссылки на файлы-обёртки в разных песочницах и запускать их по мере надобности, не покидая каталог репозитория, без необходимости работы с полными именами файла, из-за местоположения скрипта в другом каталоге.
    #!/bin/bash
    #
    # Alex Vesev @ ALT Linux, 2012-10-05
    #
    ##
    declare -r maintainerName="Alex Vesev"
    declare -r maintainerMail="*@*.*"
    declare -r dirSandBoxTop="/pathToSandbox"
    declare -r dirSandBoxHasher="${dirSandBoxTop}/hasher"
    declare -r optDirRepoHasher="--repo=\"${dirSandBoxTop}/repo/...\"" # XXX - применение не реализованно.
    function showDoc {
            cat "${0}"
    }
    [ "${#}" == 0 ] \
            && showDoc \
            && exit 1
    cliArgument="${1}"
    cliOptionName="${cliArgument%%=*}"
    cliOptionName="${cliOptionName#--}"
    cliOptionValue="${cliArgument#*=}"
    case "${cliOptionName}" in
    shell|sh)
        hsh-shell --mountpoints="/proc" "${dirSandBoxHasher}"
    ;;
    build|bu)
        gear \
            --verbose \
            --commit \
            --hasher \
            -- x86_64 \
                hsh \
                    --verbose \
                    --nprocs=2 \
                    --packager="${maintainerName} <${maintainerMail}>" \
                    --target=x86_64 \
                    --lazy-cleanup \
                    --mountpoints="/proc,/dev/pts,/sys" \
                    --apt-config="${dirSandBoxTop}/apt.conf" \
                        "${dirSandBoxHasher}"
    ;;
    rebuild|reb|rebu)
        gear \
            --verbose \
            --commit \
            --hasher \
            -- x86_64 \
                hsh-rebuild \
                    --verbose \
                    --target=x86_64 \
                    --mountpoints="/proc,/dev/pts,/sys" \
                        "${dirSandBoxHasher}"
    ;;
    install|ins)
        shift 1
        hsh-install "${dirSandBoxHasher}" "${@}"
    ;;
    clean-all)
        hsh --cleanup-only "${dirSandBoxHasher}"
    ;;
    esac


== Ссылки ==
== Ссылки ==


* [[Краткое руководство по сборке пакета]]
* [[Краткое руководство по сборке пакета]]
* Лекция Георгия Курячего "Демонстрация сборки пакета" (видео, ogv): [http://esyr.name/video/uneex/uneex_09_12_16.ogv ]
* [http://uneex.ru/LecturesCMC/PackageMaintaining2009/Video Лекции Георгия Курячего] на данную тему
** [http://esyr.name/video/uneex/uneex_09_12_16.ogv "Демонстрация сборки пакета"] (видео, ogv)
* [[О стратегии сборки RPM пакетов]]
{{Category navigation|title=Сборка пакетов|category=Сборка пакетов|sortkey={{SUBPAGENAME}}}}

Текущая версия от 22:42, 16 октября 2024

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.
Примечание: На данной вики есть еще статья Сборка пакетов start из проекта Начинающему разработчику
Примечание: На данной вики ещё есть статья Сборка пакетов (etersoft-build-utils), предлагающая минимальный порог вхождения в процесс сборки.


Данное руководство покажет, как правильно собрать пакет RPM в Sisyphus с нуля в инфраструктуре Gear и git.alt, имея только исходный код пакета, и права мейнтейнера на git.alt. В качестве примера опакетим KChildlock, чтобы закрыть запрос на сборку в багзилле: https://bugzilla.altlinux.org/25796.

Введение

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

  1. У вас установлен дистрибутив ALT Linux;
  2. Есть желание собрать пакет правильно, а не для единичного случая;
  3. Вы носите гордое звание «мейнтейнер ALT Linux Team», что подразумевает наличие электронных ключей и доступа к инфраструктуре git.alt

Третий пункт необязателен для новичков, которые просто хотят собрать пакет правильно для себя.

В ALT Linux используется формат пакетов RPM, который представляет собой архив, содержащий архив с устанавливаемыми или собираемыми файлами и заголовок с метаинформацией (например, название, версия, группа и т.п.). Различают два вида пакетов RPM:

  • Пакет с исходным кодом (имеет расширение .src.rpm). Такой пакет содержит архив (один или несколько) с исходным кодом, файл Spec (далее — просто спек) и, возможно, разнообразные патчи и дополнения. Пакет src.rpm можно использовать только для сборки двоичных пакетов, но не установки. Сборка осуществляется командой:
    rpmbuild --rebuild package...src.rpm
  • Собранный двоичный пакет (имеет расширение вида <архитектура>.rpm). В качестве архитектуры может быть i586, x86_64 или noarch. Такие пакеты можно устанавливать командой 
    rpm -Uvh package...rpm

Подробную информацию по структуре RPM и сборке с помощью команды rpm можно найти в Maximum RPM.

Однако для сборки через rpmbuild возникают очевидные сложности:

  1. Необходимо вручную удовлетворить сборочные зависимости для сборки (поставить компилятор, включаемые файлы, библиотеки). При большом количестве собираемых пакетов система засоряется.
  2. Для сборки пакета нужно сформировать .src.rpm из файлов, разбросанных по разным каталогам (по умолчанию, это подкаталоги SOURCE, SPECS и подкаталоги для сборки в ~/RPM).
  3. Файлы с исходным кодом должны лежать в упакованном виде, что делает трудоёмким процесс изготовления патчей.
  4. На рабочей системе можно упустить необходимое и достаточное количество зависимостей.


Чтобы избежать этих сложностей, в ALT Linux Team было придумано две технологии:

  • Hasher для сборки в изолированном окружении. В chroot ставится базовый комплект пакетов и пакеты, необходимые для сборки (поле BuildRequires в спеке). Если какой-то пакет для сборки не указан в спеке, то появится ошибка. Так обеспечивается чистота сборки. Обратной стороной является необходимость иметь доступ к репозиторию, так как пакеты ставятся при каждой сборке в Hasher.
  • Gear для сборки пакетов из репозитория Git. В этом случае все файлы лежат в распакованном виде и в src.rpm упаковываются по правилам, определённым в .gear/rules. Это позволяет работать сразу с содержимым, быстро делать патчи, вести историю изменений и обмениваться изменениями при коллективной разработке.

Установка пакетов для сборки

Для сборки нам потребуются следующие компоненты:

  • Любой удобный текстовый редактор (наиболее удобными являются Vim и Emacs);
  • Система управления версиями Git
  • Сборочная среда Hasher
  • Инфраструктура Gear
  • Доступ к репозиторию пакетов

Для этого настройте репозитории и установите пакеты: 

apt-get install rpm-build hasher gear

Будут установлены с зависимостями все необходимые пакеты для опакечивания и сборки.

Настройка среды

Окружение Git

Для идентификации Вашего ключа, Вашего имени, адреса электронной почты введите: 

git config --global user.name 'Andrey Cherepanov'
git config --global user.email 'cas@altlinux.org'
git config --global user.signingkey 'A9EBF131'

или 

gpg --gen-key

Измените в зависимости от ваших параметров. Третья команда задаёт идентификатор вашего GPG-ключа для подписи: 

[cas@cas ~]$ gpg --list-keys | grep -B 1 'Andrey Cherepanov'
pub   1024D/A9EBF131 2007-03-13
uid                  Andrey Cherepanov (ALT Linux Team) <cas@altlinux.ru>

или 

[cas@cas ~]$ gpg --list-secret-keys
------------------------------
sec   1024D/A9EBF131 2007-03-13
uid                  Andrey Cherepanov (ALT Linux Team) <cas@altlinux.ru>

Окружение RPM

Создайте файл ~/.rpmmacros следующего содержания (конечно, заменив ключ и имя мейнтейнера на свои): 

%packager Andrey Cherepanov <cas@altlinux.org>
%_gpg_name A424A3962331FDD2748BC8B34863C0F4A9EBF131

В %_gpg_name указывается отпечаток ключа (а не краткий идентификатор, как для Git). Получить его можно командой: 

[cas@cas ~]$ LANG=C gpg --fingerprint A9EBF131 | grep 'fingerprint =' | tr -d ' ' | cut -d= -f2
A424A3962331FDD2748BC8B34863C0F4A9EBF131

или 

[cas@cas ~]$ gpg --fingerprint A9EBF131 | sed -n '/.*=/{s/.*=/%_gpg_name\t/;s/ //gp}'
%_gpg_name	A424A3962331FDD2748BC8B34863C0F4A9EBF131

Окружение Hasher

Для начала создайте под правами root двух служебных пользователей для сборочницы (среды сборки Hasher): 

[cas@ham1 ~]$ su -
Password: 
[root@ham1 ~]# hasher-useradd cas
Adding user cas to group cas_a
Adding user cas to group cas_b
Adding user cas to group hashman

Вместо «cas» нужно указать существующего пользователя на машине, где будет развёрнута сборочная среда.

Далее для простейшей конфигурации Hasher потребуется создать каталог ~/.hasher со следующими файлами:

~/.hasher/config 

USER=cas
workdir="/tmp/.private/cas/"
target=i586
packager="`rpm --eval %packager`"
apt_config="$HOME/.hasher/apt.conf"
mount=/dev/pts,/proc

Соответственно, USER должен быть такой же, как заведён в hasher-useradd, target — указывать на архитектуру собираемых пакетов.

Подготовка репозитория Git

Репозиторий Git создать очень просто. Для этого создадим каталог (имена пакетов лучше указывать в нижнем регистре, поэтому наш пакет для проекта будет называться kchildlock), перейдём в него и запустим git init: 

mkdir kchildlock
cd kchildlock
git init .

Написание .gear/rules

Импорт исходного кода

Написание спека

Сборка в Hasher

Отправка в git.alt

Ссылки

Сборка пакетов
Сборка пакетов • Реагирует ли сборочница на переименование пакетов • Сборка пакета с git submodule • ProblemWithVerifyELFAndRPATH • Краткое руководство по сборке пакета • ALT Packaging HOWTO • Etersoft-build-utils howto • QtDesktop • Сборка пакета с нуля • Сборка проприетарного пакета с нуля • О стратегии сборки RPM пакетов • Инструкция по сборке пакетов с помощью rpm • Особенности написания спек файлов в ALT Linux • Общие правила написания спек файлов в ALT Linux • Обсуждение участника:Nir • 3rd party build • SampleSpecs • Технология сборки пакетов RPM • Join • Knobs • Сборка пакетов start • Packaging/Vendoring • RpmSetup • Spec • Spec/Предопределенные макросы • SpecTips • Руководство по написанию changelog