Etersoft-build-utils howto: различия между версиями
(Новая страница: «= 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-скриптов) и пакет отправляется на сборку в Сизиф.