Etersoft-build-utils howto

Материал из ALT Linux Wiki
Перейти к: навигация, поиск

Содержание

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

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

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

Основные преимущества:

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

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

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

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

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

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

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

Проверка наличия пакета в Сизифе[править]

$ 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 файлов.


Результат: локальный 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 просто стандартное описание исходников. Записывается это так:

# Source-url: http://example.com/%name/%name-%version.zip
Source: %name-%version.tar

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

Если исходники обновляются напрямую из git-репозитория апстрима, можно записать так:

# Source-git: http://github.com/user/repo.git
Source: %name-%version.tar

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

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


Автоматическое обновление[править]

Если в спеке правильно указан URL в Source, и в новой версии не произошло изменений в структуре файлов, достаточно выполнить команду

$ rpmrb новая_версия

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

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

Дополнительные утилиты[править]

Работа с удалённым репозиторием[править]

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

Работа с apt и rpm[править]

Для удобства управления пакетами используйте универсальный менеджер управления пакетами 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 перед использованием[править]

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

Основное, что нужно настроить:

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

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

Ссылки[править]