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

Материал из ALT Linux Wiki
(Новая страница: «= HOWTO по сопровождению пакетов с помощью etersoft-build-utils = Данные ситуации описываются для сбор...»)
 
Нет описания правки
Строка 3: Строка 3:
Данные ситуации описываются для сборки пакетов из git-репозитория, но для сборки старым способом (через ~/RPM/SPECS/спек)
Данные ситуации описываются для сборки пакетов из git-репозитория, но для сборки старым способом (через ~/RPM/SPECS/спек)
они применяются совершенно также.
они применяются совершенно также.
Применение etersoft-build-utils позволяет резко снизить порог вхождения в сборку пакетов, увеличить
скорость выполнения рутинных действий, снизить количество ошибок за счёт встроенных проверок и алгоритмизации типичных действий мантейнеров. Целью создания набора команд из этого пакета было создать высокоуровневую обвязку над существующими низкоуровневыми инструментами.


Описывается версия etersoft-build-utils 1.7.6.
Описывается версия etersoft-build-utils 1.7.6.
Основные преимущества:
* автоматическое бэкпортирование
* автоматизирование отправки на сборку
* автоматическая установка собранного пакета на проверку
* автоматическое обновление пакета до следующей версии исходников
Все команды выполняются в каталоге репозитория, как правило в том же каталоге, где лежит спек.
Все команды выполняются в каталоге репозитория, как правило в том же каталоге, где лежит спек.
Для получения описания всех параметров, допустимых для команды, её нужно вызвать с параметром -h.
Для указания сборки для бранча, нужно задать его параметром -M51 (-M50 и т.п.).


== Обзор всех команд пакета etersoft-build-utils ==


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


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


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


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


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


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


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


  rpmgp -m файл.src.rpm
  $ rpmgp -m файл.src.rpm


Команда будет вести себя также, как и для src.rpm из ALT Linux.
Как минимум в пакете нужно почистить спек и привести его надлежащему виду
Как минимум в пакете нужно почистить спек и привести его надлежащему виду
командой
командой
  rpmcs спек
  $ rpmcs спек


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


=== Собрать пакет в hasher ===
=== Собрать пакет в hasher ===
  $ rpmbsh спек
  $ rpmbsh спек
Пакет будет собран в hasher. После сборки над пакетом будут произведены проверки.
TODO: где искать результат сборки?
Для установки в тестовый hasher (для ручной проверки работоспособности пакета) после сборки пакета и последующей отправки на сборку:
$ rpmbsh -i -u спек


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


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


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


== Обновление пакета ==
== Обновление пакета ==
Строка 57: Строка 110:


Рассказать про Source-url, Source-svn в случае нестандартных ситуаций.
Рассказать про Source-url, Source-svn в случае нестандартных ситуаций.
TODO: Source-git
TODO: команды для выборочной упаковки / исключения файлов


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


[[Категория:HOWTO]]
[[Категория:HOWTO]]
[[Категория:Devel]]
[[Категория:Devel]]
[[Категория:Packaging]]
[[Категория:Packaging]]

Версия от 21:10, 8 февраля 2010

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

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

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

Описывается версия etersoft-build-utils 1.7.6.

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

  • автоматическое бэкпортирование
  • автоматизирование отправки на сборку
  • автоматическая установка собранного пакета на проверку
  • автоматическое обновление пакета до следующей версии исходников

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

Обзор всех команд пакета etersoft-build-utils

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

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

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

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

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

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

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

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

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

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

$ rpmgp -m файл.src.rpm

или

$ rpmgp -m спек

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

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

$ rpmgp -m файл.src.rpm

Команда будет вести себя также, как и для src.rpm из ALT Linux. Как минимум в пакете нужно почистить спек и привести его надлежащему виду командой

$ rpmcs спек

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

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

Собрать пакет в системе

$ rpmbb спек

Если нужно отладить только шаг установки файлов, достаточно запускать

$ rpmbb -i спек

Если нужно отладить только шаг упаковки пакета, достаточно запускать

$ rpmbb -p спек

TODO: где искать результат сборки?

Собрать пакет в hasher

$ rpmbsh спек

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

TODO: где искать результат сборки?

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

$ rpmbsh -i -u спек


Компиляция исходников

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

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

Отправить пакет на сборку в Сизиф

$ rpmbs -u спек

Бэкпортировать в 5.1 и отправить

$ rpmbph -u -M51 спек

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

Как правило, лучше использовать

$ rpmbph -i -u -M51 спек

После сборки пакета локально он будет установлен в тестовый репозиторий, где можно убедиться в его работоспособности.

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

Обновление исходников

Если в Source указан URL к файлу с исходниками, команда

$ rpmgs спек новая_версия

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

Рассказать про Source-url, Source-svn в случае нестандартных ситуаций.

TODO: Source-git

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

Для сборки старым способом рекомендуется устанавливать расширение для файлов в Source в tar.bz2.

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

Автоматическое обновление

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

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

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