Development/Tasks/Packaging/BuildSystem/Quickstart

Материал из Mandriva Russian Community Wiki

Перейти к: навигация, поиск

На этой странице представлен полный пример, который показывает, как работать с RPM-пакетами из SVN.

Содержание

Изменение пакета в SVN

Основные задачи

Чтобы обновить пакет, который находится в svn, необходимо выполнить следующее:

  • извлечь пакет из svn (или обновить пакет, если он уже извлечён);
  • внести изменения;
  • добавить новых файлы, которые необходимо внести под svn;
  • выполнить фиксацию изменений (commit) пакета;
  • предоставить пакет сборочной системе;
  • отследить успешность сборки пакета в сборочной системе.

Если вы вносите нетривиальные изменения, необходимо протестировать пакет перед фиксацией изменений. Сборку пакета можно протестировать с помощью bm (или rpmbuild). Протестировать собранный пакет можно с помощью iurt.

Инструменты и глоссарий

  • Сборочная система — набор машин сборочного кластера с планировщиком, инструментами сборки и предоставления пакетов, предназначенными для автоматизации процесса сборки пакетов, после которого пакеты попадают в репозиторий дистрибутива.
  • Сборочный кластер — набор систем, предназначенных для сборки пакетов для дистрибутива. Включает в себя системы, использующие командную оболочку, а также системы, которые запускают планировщик сборочной системы.
  • mdvsys — инструмент, который позволяет выполнять все необходимые операции с пакетом (извлечение, автоматическое обновление, внесение и т. д.), находящимся в svn.
  • repsys — инструмент, который изначально использовался Connectiva для взаимодействия со сборочной системой.
  • bm — инструмент (написан на Python), который делает сборки пакетов более удобной.

Знакомство с bm, svn, repsys

Давайте сделаем небольшое изменение, например, пакета bm, чтобы показать, как работать с SVN.

Далее предполагается, что у вас уже есть учётная запись ssh на SVN-сервере. Если у вас нет учётной записи, не отчаивайтесь. Вы можете использовать сервер cvs.mandriva.com через https:// вместо svn+ssh:// на svn.mandriva.com. Вы не сможете внести сделанные изменения, но по крайней мере увидите, как работают программы checkout и diff.

Аутентификация

Первым делом давайте добавим идентификацию ssh в ssh-agent, чтобы не вводить каждый раз пароль (см. en:Development/Docs/Contributor_Tricks#SSH_configuration to configure your ssh agent):

[andreas@pandora svn]$ ssh-add
Enter passphrase for /home/andreas/.ssh/id_dsa:
Identity added: /home/andreas/.ssh/id_dsa (/home/andreas/.ssh/id_dsa)

Если команда ssh-add вернула ошибку, необходимо запустить ssh-agent вручную:

[zeb@n4 svn]$ exec ssh-agent bash

затем, добавьте ключ с помощью команды ssh-add.

Извлечение (checkout)

Теперь давайте извлечём текущую версию bm из SVN:

[andreas@pandora svn]$ svn co svn+ssh://svn.mandriva.com/svn/packages/cooker/bm/current bm
A    bm/SOURCES
A    bm/SOURCES/bm-2.1-rpmbuild.patch.bz2
A    bm/SOURCES/bm-2.1.tar.bz2
A    bm/SPECS
A    bm/SPECS/bm.spec
Checked out revision 975.

Это приведёт к созданию локального каталога bm. Спеки будут находиться в подкаталоге SPECS, а исходники — в SOURCES. Давайте внесём изменения.

[andreas@pandora svn]$ cd bm
[andreas@pandora bm]$ bunzip2 SOURCES/bm-2.1-rpmbuild.patch.bz2
[andreas@pandora bm]$ vi SPECS/bm.spec

Помните, что мы работает внутри извлечённого из svn каталога.

Давайте посмотрим, что же мы изменили в результате нашей работы:

[andreas@pandora bm]$ svn status
?      SOURCES/bm-2.1-rpmbuild.patch
!      SOURCES/bm-2.1-rpmbuild.patch.bz2
M      SPECS/bm.spec

Первая строка говорит нам, что в каталоге SOURCES появился новый файл, о котором SVN ничего не известно. Отсюда и обозначение в виде вопросительного знака. Во второй строке показано предупреждение о том, что файл, который находился под контролем версий (svn), пропал. Вполне справедливо, поскольку мы переименовали файл, когда убирали сжатие bzip2.

Поэтому, нужно удалить .bz2 из-под контроля версий и добавить под контроль .patch:

[andreas@pandora bm]$ svn rm SOURCES/bm-2.1-rpmbuild.patch.bz2
D         SOURCES/bm-2.1-rpmbuild.patch.bz2
[andreas@pandora bm]$ svn add SOURCES/bm-2.1-rpmbuild.patch
A         SOURCES/bm-2.1-rpmbuild.patch

Теперь команда svn status говорит, что всё нормально:

[andreas@pandora bm]$ svn status
D      SOURCES/bm-2.1-rpmbuild.patch.bz2
A      SOURCES/bm-2.1-rpmbuild.patch
M      SPECS/bm.spec

Проверка сборки

Быстрая проверка

Можно собрать наш пакет, чтобы удостовериться, что всё нормально. Мы сделаем это снова внутри извлечённого каталога. Мы используем bm тут, потому что он позволяет собрать RPM-пакет вне %_topdir (обычно ~/rpm):

[andreas@pandora bm]$ bm
creating package list
processing package bm-2.1-1mdk
building source and binary packages
error: File /home/andreas/svn/bm/SOURCES/bm-2.1-rpmbuild.patch.bz2: No such file or directory
error: failed!

Ой! Нехорошо вносить то, что не собирается... Одна небольшая поправка и пробуем снова:

[andreas@pandora bm]$ vi SPECS/bm.spec
[andreas@pandora bm]$ bm
creating package list
processing package bm-2.1-1mdk
building source and binary packages
succeeded!

Файл с журналом можно найти в каталоге SPECS/log.bm. Чтобы включить вывод сообщений журнала на экран, используйте bm -l.

Извлечение в чистый chroot

Поскольку сервер сборочной системы собирает пакеты в чистом chroot, рекомендуется проверить, успешно ли собираются пакеты в чистом окружении. В частности, это помогает при отладке раздела BuildRequires спек-файла. Если пакет успешно собрался на узле, но не на сервере сборочной системы, это означает, что в разделе BuildRequires чего-то не хватает. Чтобы проверить, собирается ли ваш пакет в чистом chroot перед предоставлением пакета сборочной системе, используйте Iurt:

[zeb@n4 bm]$ cd SRPMS
[zeb@n4 SRPMS]$ sudo iurt bm-2.1-214mdv2007.1.src.rpm

Проверка на других архитектурах

Сборочная система пытается собрать пакет для i586 и x86_64, и если сборка пакета заканчивается неудачно, пакет будет отклонён. Для этого войдите на один из 64-битных узлов (deborah или seggie), пересоберите пакет в этом окружении с помощью bm или Iurt.

В случае возникновение проблем для одной из архитектур, в спек-файле можно использовать условия (например, когда одна из архитектур требует иных параметров для команды ./configure):

%ifarch x86_64
# ...this will be executed in the x86_64 machine only
%else
# ...this will be exectuted in the i586 machine
%endif

Чтобы полностью исключить архитектуру, используйте в спек-файле инструкцию Buildarch. В частности, эта инструкция используется при сборке независящих от архитектуры пакетов:

Buildarch   : noarch

Просмотр изменений

Теперь можно зафиксировать (commit) сделанные изменения. Хорошей практикой считается предварительный просмотр сделанных изменений перед их фиксацией. Эта процедура также помогает при создании сообщений для журнала (журналы фиксации изменений используются вносятся в список изменений пакета).

[andreas@pandora bm]$ svn diff
Index: SOURCES/bm-2.1-rpmbuild.patch.bz2
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: SOURCES/bm-2.1-rpmbuild.patch
===================================================================
--- SOURCES/bm-2.1-rpmbuild.patch       (revision 0)
+++ SOURCES/bm-2.1-rpmbuild.patch       (revision 0)
@@ -0,0 +1,15 @@
+diff -ur bm-2.1/BuildManager/build.py bm-2.1.acme/BuildManager/build.py
+--- bm-2.1/BuildManager/build.py       2003-11-20 15:37:22.000000000 -0200
++++ bm-2.1.acme/BuildManager/build.py  2004-01-17 14:58:57.843281631 -0200
+@@ -198,9 +198,9 @@
+                 tmppath = " --define '_tmppath %s/BUILDROOT'" % pkg.builddir
+             else:
+                 tmppath = ""
+-            cmd = "rpm -b%s --define '_topdir %s'%s %s %s 2>&1" % \
++            cmd = "rpmbuild -b%s --define '_topdir %s'%s %s %s 2>&1" % \
+                   (stagechar,pkg.builddir,tmppath,passtrough,pkg.spec)
+-            logger.debug("rpm command: "+cmd)
++            logger.debug("rpmbuild command: "+cmd)
+             if not dryrun:
+                 log = open(pkg.log, "w")
+                 pop = popen2.Popen3(cmd)
Index: SPECS/bm.spec
===================================================================
--- SPECS/bm.spec       (revision 975)
+++ SPECS/bm.spec       (working copy)
@@ -3,6 +3,6 @@
 %define py_libdir  %{py_prefix}/%{_lib}/python%{py_ver}
 %define py_sitedir %{py_libdir}/site-packages

 Name: bm

 Version: 2.1
 Release: 1mdk
@@ -11,7 +15,7 @@
 License: GPL
 URL: http://moin.conectiva.com.br/BuildManager
 Source: bm-%{version}.tar.bz2
-Patch: bm-2.1-rpmbuild.patch.bz2
+Patch: bm-2.1-rpmbuild.patch
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
 Requires: python >= %pyver
 Requires: rpm-build

Фиксация изменений (commit)

svn ci -m 'remove compression for the patch'

Предоставление пакета

После фиксации изменений нужно предоставить пакет.

Чтобы предоставить пакет bm cooker, необходимо запустить команду:

repsys submit svn+ssh://svn.mandriva.com/svn/packages/cooker/bm 976

В случае успеха будет предоставлен пакет bm ревизии 976 (подробнее см. Submitting in detail).

Вы можете опустить часть URL и просто использовать название пакета, если /etc/repsys.conf правильно сконфигурирован с параметром default_parent.

Примечание
ssh-agent должен быть правильно настроен, иначе команда предоставления не пройдёт!

Важно отметить, что процесс предоставления не требует доступа к файлу .src.rpm! Предоставление пакета сродни телефонному звонку: "Выгрузите пакет bm. Спасибо."

Знакомство с mdvsys

mdvsys — это часть скрипта пакета perl-MDV-Repsys, который используется вместо repsys. mdvsys можно использовать для большинства команд svn при работе с RPM-пакетами, хранящимися в svn.

mdvsys требует установленного и настроенного repsys, поскольку они оба используются один и тот же конфигурационный файл /etc/repsys.conf).

Далее приводятся примеры использования mdvsys (в примерах используется пакет xinetd). Вы увидите, что использование mdvsys позволяет избежать некоторой рутины.

Извлечение

mdvsys co xinetd

Синхронизация изменений

Измените спек-файл:

$ cd pkg-dir
$ emacs|vi SPECS/pkg.spec

Добавьте/удалите файл в репозиторий после изменений:

mdvsys sync

Сборка

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

mdvsys build

Фиксация изменений

Проверьте пакет, если всё нормально, зафиксируйте изменения:

mdvsys ci -m 'some greate changes'

Предоставление

mdvsys submit xinetd

Импортирование пакета в SVN

Чтобы импортировать новый пакет в SVN, используйте инструмент srpm2svn.sh (из своей машины, кластера, откуда угодно):

$ srpm2svn.sh /mnt/BIG/distrib/cooker/SRPMS/main/release/bm-2.1-212mdk.src.rpm

Этот скрипт расположен в http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/build_system/srpm2svn/trunk/ и требует установки следующих пакетов:

  • perl-MDV-Repsys
  • repsys (для файла /etc/repsys.conf: проверьте файл на наличие корректного URL)

Вы также можете использовать непосредственно команду mdvsys import src.rpm [src.rpm ...].