Просмотр кода страницы Etersoft-build-utils howto

= HOWTO по сопровождению пакетов с помощью etersoft-build-utils =

Применение etersoft-build-utils позволяет резко снизить порог вхождения в сборку пакетов, увеличить скорость выполнения рутинных действий, снизить количество ошибок за счёт встроенных проверок и алгоритмизации типичных действий мантейнеров. Целью создания этого набора команд  было создать высокоуровневую обвязку над существующими низкоуровневыми инструментами.

Описывается версия etersoft-build-utils 2.0. Впервые пакет был собран в Сизиф 28 февраля 2005 года.
Пожелания на документирование ещё не описанных ситуаций принимаются на [[Обсуждение:Etersoft-build-utils_howto|странице обсуждения]].

Основные преимущества:
* автоматическое бэкпортирование (сборка для бранча)
* автоматизирование отправки на сборку
* автоматическая установка собранного пакета на проверку
* автоматическое обновление пакета до следующей версии исходников
* запись лога сборки пакета
* поддержка удалённой сборки
* интерфейс (команды и параметры) не меняются с изменением технологий

Все команды стараются достичь интуитивно ожидаемого результата во всех случаях, где возможно различное поведение в зависимости от ситуации (например, rpmbsh сработает, если указать ей src.rpm или спек).
Обычно команды выполняются в каталоге репозитория, как правило в том же каталоге, где лежит спек.
Для получения описания всех допустимых параметров, вызовите команду с параметром -h. 

Для указания сборки для бранча, нужно задать его параметром -b p8 (-b t7 и т.п.).

Данные ситуации описываются для сборки пакетов из git-репозитория, но для сборки старым способом (через ~/RPM/SPECS/спек) они применяются совершенно также.

Логи сборки пакета записываются в каталог <code>~/RPM/log</code>.

== Получение готового к сборке репозитория ==

С чего начинаем, чтобы получить репозиторий.

=== Проверка наличия пакета в Сизифе ===
 $ rpmgp -c название_пакета
Команда выведет доступные репозитории у разных пользователей с этим пакетов, указав дату последнего изменения в репозитории.
Если пакет установлен в системе, или вместо названия пакета указан файл спека, то будет проверено наличие данной версии пакета в Сизифе. Это удобно для выявления необходимости пересборки пакета.

Результат: выведенная в консоль информация о пакете.

=== Подхватывание уже собранного в Сизиф пакета ===

 $ rpmgp -gm название_пакета

Команда возьмёт репозиторий, из которого последний раз пакет собирался в Сизиф (из git.alt /srpms или /gears),
клонирует в git.alt:packages/название_пакета.git, из git.alt клонирует локально (создав репозиторий в текущем каталоге),
причём все имеющиеся ветки.

Эта команда удобна для быстрого перехода со сборки по устаревшей схеме на git.

Результат: локальный и удалённый репозитории с последней версией пакета.

=== Берём имеющийся src.rpm для ALT ===

 $ rpmgp -m файл.src.rpm
или
 $ rpmgp -m спек

Команда создаст репозиторий с названием пакета в текущем каталоге (можно задать в конфиге переменной GITREPODIR) и импортирует в него указанный пакет с помощью gear-srpmimport.

Результат: локальный git-репозиторий с пакетом.

=== Берём src.rpm от другого дистрибутива ===

Сначала ищем пакет (выполняется поиск в репозиториях систем, основанных на RPM: Fedora, ROSA, и т.д.):
 $ rpmgp -a название
Потом скачиваем подходящий
 $ rpmgp -a -d название-пакета
Потом превращаем его в git-репозиторий:
 $ rpmgp -m файл.src.rpm
В созданном git-репозитории будет автоматически запущена
 $ rpmcs спек
чтобы почистить спек.

После автоматической конвертации спека его нужно привести в соответствие принятым в ALT Linux требованиям к спеку. См. [[Spec|Описание spec файлов]].


Результат: локальный git-репозиторий с пакетом.

=== Создаём репозиторий с нуля ===


== Сборка пакета ==

=== Собрать пакет в системе ===
 $ rpmbb
Если нужно отладить только шаг установки файлов, достаточно запускать
 $ rpmbb -i
Если нужно отладить только шаг упаковки пакета, достаточно запускать
 $ rpmbb -p

Результат: собранный пакет в ~/RPM/RPMS.

=== Собрать пакет в hasher ===
 $ rpmbsh
Пакет будет собран в hasher. После сборки над пакетом будут произведены проверки.

Результат: собранный пакет в ~/hasher-SS/repo/i586/RPMS.hasher/.

Для установки в тестовый hasher (для ручной проверки работоспособности пакета) после сборки пакета и последующей отправки на сборку:
 $ rpmbsh -i -u

== Отправка пакета на сборку ==

Отправка пакета на сборку в сборочницу выполняется командой rpmbs, которая может быть вызвана другими командами, которым указан параметр -u.
По умолчанию используется сборочница git.alt, но первым параметром любой команды, отправляющей на сборку, может быть указана другая сборочница, например git.eter.

===Отправить пакет на сборку в Сизиф===
 $ rpmbs -u

Будет создан тег, соответствующей текущему состоянию пакета, репозиторий опубликован (удалённый репозиторий будет создан при необходимости) и создано задание на сборку по тегу (вида VERSION-RELEASE).

Результат: созданное задание на сборку пакета.

===Бэкпортировать в p7 и отправить===
 $ rpmbph -b p7 -u

Команда обновит ветку p7 из текущей (создаст ветку p7, если её ещё не было),
сконвертирует текущий спек (предложив посмотреть на выполненные изменения, от которых можно отказаться нажатием Ctrl-\ перед выходом кнопкой q), соберёт полученный репозиторий локально и отправит пакет на сборку в соответствующий бранч.

Параметр -n запретит сборку локально (используйте только, если уверены в том, что всё будет хорошо).

Как правило, лучше использовать
 $ rpmbph -b p7 -i -u
После сборки пакета локально он будет установлен в тестовый репозиторий, где можно убедиться в его работоспособности.

Результат: созданное задание на сборку пакета.

== Обновление пакета ==

=== Обновление исходников ===
Если в Source указан URL к файлу с исходниками, команда
 $ rpmgs [-f] новая_версия
скачает новый архив с исходниками, перебрав все возможные варианты форматов (расширений) и сконвертировав в tar (tar.bz2),
если в Source указано расширение .tar (.tar.bz2).

Для удобства можно указать настоящий путь в Source-url, а в Source просто стандартное описание исходников. Записывается это так:
<pre>
# Source-url: http://example.com/%name/%name-%version.zip
Source: %name-%version.tar
</pre>

Результат: обновление каталога с исходниками в виде одного коммита.

Если исходники обновляются напрямую из git-репозитория апстрима, можно записать так:
<pre>
# Source-git: http://github.com/user/repo.git
Source: %name-%version.tar
</pre>

В результате при выполнении обновления будет добавлен upstream в список remote, выполнен git fetch и git merge тега,
соответствующего версии, указанной в спеке в Version: (будут проверены варианты v1.2.0 и 1.2.0).

TODO: команды для выборочной упаковки / исключения файлов

<!--Для сборки через git рекомендуется указывать .tar (одновременно нужно сменить указание способа архивации и в ~/.gear/rules).-->


=== Автоматическое обновление ===
Если в спеке правильно указан URL в Source, и в новой версии не произошло изменений в структуре
файлов, достаточно выполнить команду
 $ rpmrb новая_версия
Она выполняет достаточно простые действия, выполняя последовательно команды rpmgs, rpmbsh -i, rpmbs:
скачивает новые исходники, обновляет спек, собирает пакет в hasher, ставит собранный пакет в тестовый hasher и предлагает
командную строку для тестирования пакета. После выхода из тестирования проверяется отсутствие проблем при удалении пакетов (проверка post-скриптов) и пакет отправляется на сборку в Сизиф.

Результат: собранный и проверенный пакет, задание на сборку пакета.

== Дополнительные утилиты ==

=== Работа с удалённым репозиторием ===

* ginit [git.NAME] - создание удалённого репозитория
* gpush [-f] [git.NAME] - публикация текущей ветки 
* gpull [git.NAME] - обновление текущей ветки из удалённого репозитория (не изучено)

=== Работа с apt и rpm ===
Для удобства управления пакетами используйте универсальный менеджер управления пакетами [http://wiki.etersoft.ru/Epm EPM].

=== Компиляция исходников ===
В случае ручного запуска компиляции (например внутри ~/RPM/BUILD) удобно использовать
команду jmake. Она соберёт с использованием всех ядер (параметр -j для make), невысоким приоритетом (nice) и задействует ccache для ускорения повторных сборок.

=== Тестирование пакетов ===
Войти в hasher:
 loginhsh -t [-i] [-r] название-пакета или/и полный_путь_к_файлу_пакета
* -i - инициализировать перед входом
* -r - войти под рутом

=== Просмотр баги по пакету ===

 $ rpmbugs [название пакета|номер баги]

rpmbugs отображает список багов по пакету в браузере или консоли (через xdg-open или links).

=== Определение принадлежности файла к пакету ===

 $ epmqf [программа|путь к файлу]

epmqf выводит название пакета, который содержит указанную программу (примерно это поиск по PATH с помощью which)
или указанный файл, при этом раскрывает ссылки, так что работает и при использовании механизма альтернатив.

=== Открытие ссылок из пакета ===

Открыть ссылку (поле Url в пакете):
 $ rpmurl спек или пакет

Открыть страницу пакета на http://sisyphus.ru:
 $ rpmurl -p спек или пакет

Открыть ссылку, по которой расположен файл с исходным кодом (поле Source в пакете):
 $ rpmurl -s спек или пакет

=== Проверка собранных пакетов на нарушение зависимостей ===

Для вывода нарушенных собранными в hasher пакетами:
 $ rpmunmets [-s] [-b p8]

== Необходимые настройки etersoft-build-utils перед использованием ==

Параметры, подлежащие настройке, могут быть заданы в <code>/etc/eterbuild/config</code> (содержащем примеры) или в <code>~/.config/eterbuild</code>.

Основное, что нужно настроить:
* HASHERBASEDIR - путь, где будет создаваться каталог hasher (по умолчанию - ~/hasher)
* ''требуется дописать''

В каталоге <code>/etc/eterbuild/apt</code> лежат конф. файлы для различных целевых платформ (M40, M51...),
которые будут использоваться для сборки в hasher.

== Ссылки ==
* [[Сборка пакетов (etersoft-build-utils)]].
* Описание пакета [[etersoft-build-utils]].

[[Категория:Devel]]
[[Категория:Packaging]]
{{Category navigation|title=Сборка пакетов|category=Сборка пакетов|sortkey={{SUBPAGENAME}}}}