Etersoft-build-utils howto: различия между версиями
мНет описания правки |
|||
Строка 35: | Строка 35: | ||
Результат: выведенная в консоль информация о пакете. | Результат: выведенная в консоль информация о пакете. | ||
=== | === Подхватывание уже собранного в Сизиф пакета === | ||
$ rpmgp -g название_пакета | $ rpmgp -g название_пакета | ||
Строка 185: | Строка 185: | ||
mkpatch файл - создаёт патч относительно файл.orig или основываясь на информации из репозитория git, svn или git. | mkpatch файл - создаёт патч относительно файл.orig или основываясь на информации из репозитория git, svn или git. | ||
=== | === Просмотр баги по пакету === | ||
$ rpmbugs [название пакета|номер баги] | $ rpmbugs [название пакета|номер баги] |
Версия от 12:38, 9 февраля 2010
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 -g название_пакета
Команда возьмёт репозиторий, из которого последний раз пакет собирался в Сизиф (из 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 -m файл.src.rpm
Команда будет вести себя также, как и для src.rpm из ALT Linux. Как минимум в пакете нужно почистить спек и привести его надлежащему виду командой
$ 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).
Результат: созданное задание на сборку пакета.
Бэкпортировать в 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-скриптов) и пакет отправляется на сборку в Сизиф.
Результат: собранный и проверенный пакет, задание на сборку пакета.
Дополнительные утилиты
Работа с удалённым репозиторием
- ginit [git.NAME] - создание удалённого репозитория
- gpush [-f] [git.NAME] - публикация текущей ветки
- gpull [git.NAME] - обновление текущей ветки из удалённого репозитория (не изучено)
Работа с apt и rpm
Сокращения для bash:
- 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, которые порождают трёхуровневые ссылки.
Компиляция исходников
В случае ручного запуска компиляции (например внутри ~/RPM/BUILD) удобно использовать команду jmake. Она соберёт с использованием всех ядер (параметр -j для make), невысоким приоритетом (nice) и задействует ccache для ускорения повторных сборок.
Тестирование пакетов
Войти в hasher:
loginhsh -t [-i] [-r] название-пакета или/и полный_путь_к_файлу_пакета
- -i - инициализировать перед входом
- -r - войти под рутом
Создание патча
mkpatch файл - создаёт патч относительно файл.orig или основываясь на информации из репозитория git, svn или git.
Просмотр баги по пакету
$ rpmbugs [название пакета|номер баги]
rpmbugs отображает список багов по пакету в браузере или консоли (через xdg-open или links).
Открытие ссылок из пакета
Открыть ссылку (поле Url в пакете):
$ rpmurl спек или пакет
Открыть страницу пакета на http://sisyphus.ru:
$ rpmurl -p спек или пакет
Открыть ссылку, по которой расположен файл с исходным кодом (поле Source в пакете):
$ rpmurl -s спек или пакет
Проверка собранных пакетов на нарушение зависимостей
Для вывода нарушенных собранными в hasher пакетами:
$ rpmunmets [-s] [-M51]
Необходимые настройки etersoft-build-utils перед использованием
Параметры, подлежащие настройке, могут быть заданы в /etc/eterbuild/config
(содержащем примеры) или в ~/.config/eterbuild
.
Основное, что нужно настроить:
- HASHERDIR - путь, где будет создаваться каталог hasher (по умолчанию - ~/hasher)
- требуется дописать
Ссылки
- Сборка пакетов (etersoft-build-utils).
- Описание пакета etersoft-build-utils.