Etersoft-build-utils howto: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
Нет описания правки
Строка 37: Строка 37:
=== Подхватывание уже собранного в Сизиф пакета ===
=== Подхватывание уже собранного в Сизиф пакета ===


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


Команда возьмёт репозиторий, из которого последний раз пакет собирался в Сизиф (из git.alt /srpms или /gears),
Команда возьмёт репозиторий, из которого последний раз пакет собирался в Сизиф (из git.alt /srpms или /gears),
Строка 53: Строка 53:
  $ rpmgp -m спек
  $ rpmgp -m спек


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


Результат: локальный git-репозиторий с пакетом.
Результат: локальный git-репозиторий с пакетом.
Строка 59: Строка 59:
=== Берём src.rpm от другого дистрибутива ===
=== Берём src.rpm от другого дистрибутива ===


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


Команда будет вести себя также, как и для src.rpm из ALT Linux.
После автоматической конвертации спека его нужно привести в соответствие принятым в ALT Linux требованиям к спеку. См. [[Spec|Описание spec файлов]].
Как минимум в пакете нужно почистить спек и привести его надлежащему виду
командой
$ rpmcs спек
После автоматической конвертации спека его нужно привести в соответствие принятым в ALT Linux требованиям к спеку. См. [http://www.altlinux.org/Spec Описание spec файлов].




Строка 76: Строка 80:


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


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


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


Строка 91: Строка 95:


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


== Отправка пакета на сборку ==
== Отправка пакета на сборку ==
Строка 99: Строка 103:


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


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


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


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


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


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


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


TODO: Source-git
TODO: Source-git
Строка 132: Строка 141:
TODO: команды для выборочной упаковки / исключения файлов
TODO: команды для выборочной упаковки / исключения файлов


Для сборки старым способом рекомендуется устанавливать расширение для файлов в Source в tar.bz2.
Для сборки через git рекомендуется указывать .tar (одновременно нужно сменить указание способа архивации и в ~/.gear/rules).
 
Для сборки через git рекомендуется указывать .tar (одновременно нужно сменить указание способа
архивации и в ~/.gear/rules).


Результат: обновление каталога с исходниками в виде одного коммита.
Результат: обновление каталога с исходниками в виде одного коммита.
Строка 142: Строка 148:
Если в спеке правильно указан URL в Source, и в новой версии не произошло изменений в структуре
Если в спеке правильно указан URL в Source, и в новой версии не произошло изменений в структуре
файлов, достаточно выполнить команду
файлов, достаточно выполнить команду
  $ rpmrb спек новая_версия
  $ rpmrb новая_версия
Она выполняет достаточно простые действия, выполняя последовательно команды rpmgs, rpmbsh -i, rpmbs:
Она выполняет достаточно простые действия, выполняя последовательно команды rpmgs, rpmbsh -i, rpmbs:
скачивает новые исходники, обновляет спек, собирает пакет в hasher, ставит собранный пакет в тестовый hasher и предлагает
скачивает новые исходники, обновляет спек, собирает пакет в hasher, ставит собранный пакет в тестовый hasher и предлагает
Строка 158: Строка 164:


=== Работа с apt и rpm ===
=== Работа с apt и rpm ===
Сокращения для bash:
Для удобства управления пакетами используйте универсальный менеджер управления пакетами [http://wiki.etersoft.ru/Epm EPM].
* apti - sudo apt-get install
* apts - apt-cache search
* apto - apt-cache show
* aptw - apt-cache whatdepends
 
Команды:
* rpmU - [sudo] rpm -Uvh
* rpmqf - аналог rpm -qf, (может действовать и как rpm -qf `which FILE`)
 
rpmqf работает рекурсивно, и хорошо справляется с альтернативами в /usr/bin, которые порождают
трёхуровневые ссылки.


=== Компиляция исходников ===
=== Компиляция исходников ===
Строка 180: Строка 175:
* -i - инициализировать перед входом
* -i - инициализировать перед входом
* -r - войти под рутом
* -r - войти под рутом
=== Создание патча ===
mkpatch файл - создаёт патч относительно файл.orig или основываясь на информации из репозитория git, svn или git.


=== Просмотр баги по пакету ===
=== Просмотр баги по пакету ===
Строка 193: Строка 184:
=== Определение принадлежности файла к пакету ===
=== Определение принадлежности файла к пакету ===


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


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



Версия от 19:31, 11 августа 2015

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

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

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

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

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

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

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

Данные ситуации описываются для сборки пакетов из 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 от другого дистрибутива

Сначала ищем пакет:

$ 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 новая_версия

скачает новый архив с исходниками, перебрав все возможные варианты форматов (расширений) и сконвертировав в tar (tar.bz2), если в Source указано расширение .tar ( .tar.bz2).

Для удобства можно указать настоящий путь в Source-url, а в Source просто стандартное описание исходников. Записывается это так:

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

TODO: Source-git

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

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

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

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

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

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

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

Ссылки