Как стать mantainer'ом пакета в Fedora. Конспект

Предисловие

Этот конспект я вел исключительно для собственных нужд. Поэтому этот текст не является руководством, это необходимо понять прежде всего - это краткий конспект. Вместо любых разъяснений даны ссылки на исчерпывающие материалы по теме, которые обновляются, как и принято в комьюнити, более сведущими специалистами. В этом тескте также нет правильных переводов терминов.

Конспект написан по причине того, что в федора-вики много информации по теме, и, вместе с тем, некоторые особенности освещены слабо. По крайней мере, это вызвало у меня, как у ньюба, затруднения. Но, в целом, повторюсь, информации по данной теме в федора-вики много, англоязычной, естественно.

Автор выражает надежду, что изложенная информация будет полезна для успешного старта.

Начало

Источники:

Дополнительно

Перво-наперво посмотреть нет ли уже такого пакета в :

Fedora Package Database
в списке Review Request
а также в списке https://bugzilla.rpmfusion.org/ (прим. авт.: я так "накололся" с mocp - "изобрел" spec, который уже был на ревью в rpmfusion)

Можно взять спек от похожей проги (а лучше несколько)

$ yumdownloader --source sourcepackage-name

Настройка системы

How to create an RPM package

# yum groupinstall "Development Tools"
# yum install rpmdevtools

Создать отдельного юзера под которым будут собираться пакеты:

# /usr/sbin/useradd makerpm

Создать дерево каталогов, необходимое для сборки

$ rpmdev-setuptree

Имена

Packaging:NamingGuidelines

Допустимые символы для именования пакета

  a--z  A--Z 0--9
  -._+

При присвоении имен пакетов для Fedora, мантайнеру необходимо использовать - в качестве разделителя для названия частей. Мантайнер **НЕ** должен юзать _ + . в качестве разделителя.

Имя spec файла по схеме : %{имя пакета}.spec. Если имя пакета foo-1.0.0-1.src.rpm, то имя spec файла д.б. foo.spec

%{номер версии} не нужно писать в имени spec файла.

Поле Version в спеке должно быть.

release number (или в старых доках vepoch) начинается с 1. При незначительных изменениях он увеличивается на 1. При значительных изменениях увеличивается version number и release number опять начинается с 1.

См. также Packaging:DistTag.

Pre-Release

Release Tag для Pre-Release Packages:

0.%{X}.%{alphatag}

где %{X} - release number (увеличивается на 1), %{alphatag} строка из версии.

Пример для release candidate 1

#define alphatag rc1

См. также Software release life cycle для общего развития.

Snapshot packages

Нумеруются как Pre-Release packages

0.%{X}.%{alphatag}

где %{X} это release number (увеличивается на 1), %{alphatag} начинается в формате YYYYMMDD и далее, например, хэш Git.

Создание SPEC

См. также :

Создаем заготовку

$ cd ~/rpmbuild/SPECS
$ rpmdev-newspec  program
$ vi program.spec

Далее см. Spec file pieces explained

Вывести список наименований групп софта (поле Group спека)

less /usr/share/doc/rpm-4.6.1/GROUPS

или

LANG=C; yum grouplist

Смотреть какие пакеты входят в группу, например "System Tools" :

yum groupinfo "System Tools"

Чтобы посмотреть, как разворачивается макрос %makeinstall

rpm --eval '%makeinstall'

Или любой другой макрос для определенного спека, например

rpmbuild -E '%{_bindir}' myfile.spec

секция %install

Команды этой секции копируют файлы из "build directory" %{_builddir}, обычно это

  ~/rpmbuild/BUILD/something

# пример
  ~/src/BUILD

в %{buildroot}, обычно это

  /var/tmp/something

# пример
  ~/src/BUILDROOT/%{name}-%{version}-%{release}.i386

и создают подкаталоги в %{buildroot} если нужно.

Внимание, эта терминология очень запутанна.

каталоги build (где происходит компиляция в стадии %build) и build root (куда файлы копируются в процессе %install) - это разные каталоги.
%install скрипт не устанавливает rpm пакет!! Термин %install запутывающий, скрипт устанавливает программу НЕ в реальную конечную локацию (типа /usr/bin), а в %{buildroot}.

Сборка

Быстрое тестирование:

rpmlint program.spec

Сборка

rpmbuild -ba program.spec

Это будет попытка выполнить следующие этапы:

%prep (preparation) этап подготовки. Распаковка и установка исходников и патчей в %_builddir (подкаталог ~/rpmbuild/BUILD)
%build этап, компиляция файлов, которые будут установлены в _builddir%. Обычно это какой-то эквивалент "make".
%install этап, копирование файлов из %_builddir (который подкаталог ~/rpmbuild/BUILD) в каталог %{buildroot}. Каталог buildroot ранее установлен в "BuildRoot:"; если вы оставите его в обычном значении начинающемся %{_tmppath}/%{name}..., то buildroot будет внутри /var/tmp.
создание бинарного и source RPM пакетов (.rpm и .src.rpm). Бинарный RPM создается с использованием информации из %files файлов.

Если что-то пошло не так, вы можете перейти в соответствующий каталог и посмотреть, что осталось. Если вы хотите пропустить более ранние стадии установки советуем использовать опцию "--short-circuit". Это удобно, если у вас была успешна стадия build, но есть ошибка в %install секции.

Например:

$ rpmbuild -bi --short-circuit program.spec

Тестирование

Смотреть список файлов

rpmls *.rpm

Тест

$ rpmlint <имя>.rpm

# или

$ rpmlint -i <имя>.rpm

webacula.noarch: E: htaccess-file /usr/share/webacula/html/.htaccess
webacula.noarch: W: dangling-symlink /usr/share/webacula/library/Zend /usr/share/php/Zend
webacula.noarch: E: executable-marked-as-config-file /etc/cron.daily/webacula_clean_tmp.sh
webacula.noarch: W: file-not-utf8 /usr/share/doc/webacula-3.2.1/INSTALL.es
webacula.noarch: E: zero-length /usr/share/webacula/application/views/scripts/index/index.phtml

Просмотреть инфу по ошибке, например

$ rpmlint -I htaccess-file

htaccess-file:
You have individual apache configuration .htaccess file(s) in your package.
Replace them by a central configuration file in /etc/, according to the web
application packaging policy for your distribution.

Если все ок, то установите пакет

rpm -ivp [package].rpm
rpm -e [package]

Сбока под mock. Вы д.б. в группе mock

$ cd ~/src/SRPMS
$ mock -r fedora-11-i386 rebuild webacula-3.2.1-1.fc10.src.rpm

Прим. mock скачивает файлы в /var/lib/mock

Какие типичные ошибки можно сделать, даже хорошо подготовившись, см. мой Review Request.

koji

Если mock отработал ок, то сборка под koji. Настройка koji описана здесь: Using the Koji build system, Join the package collection maintainers

Сгенерить сертификат Fedora Account System.

Сохранить его под именем ~/.fedora.cert, запустить

$ fedora-packager-setup

Теперь можно логиниться в Koji Build System

$ koji build --scratch dist-f11 webacula-3.2.1-1.fc10.src.rpm

При этом на странице https://koji.fedoraproject.org/koji/ будет виден прогресс и логи.

Review Request

Для примера см. мой Review Request.

Обязательно подписаться на fedora-devel-announce@redhat.com

Также можно подписаться на fedora-devel-list@redhat.com

Получить помощь можно также на канале #fedora-devel на freenode.

Разместить свой SRPM и SPEC файлы где-нибудь в инете.

Создать "Review Request" заполнив форму.

Объяснить в поле 'Review Description', что это первый пакет и нужен поручитель: That this is my first package and I need a sponsor.

В поле Blocks указать баг FE-NEEDSPONSOR.

См. также How to get sponsored

Потенциальные поручители просматривают FE-NEEDSPONSOR баг в багзилле.

Кто-нибудь рассмотрит ваш пакет. Пока нет рецензента (поручителя) флаг fedora-review flag будет пуст. fedora-review flag будет установлен в +, когда пакет пройдет рассмотрение.

См. также Definitions for fedora-review Flag Settings

Подробнее процесс описан в Package Review Process

Я искал поручителя на irc-каналах в т.ч. русскоязычных.

Спонсор

Когда Review Request одобрен рецензентом (reviewer), надо найти спонсора (sponsor).

Рассмотрение и утверждение на первый пакет для новых упаковщиков (packagers) должно быть сделано зарегистрированным спонсором. Последующие обзоры (reviews) м.б. сделаны любым сопровождающим (maintainer) пакета. Неофициальные отзывы всегда может сделать любое заинтересованное лицо.

CVS

После успешного завершения фазы Review Request надо выполнить CVS admin requests

В том же сам баге установить флаг fedora-cvs в ? и в каменте описать по шаблону

New Package CVS Request
=======================
Package Name: webacula
Short Description: Webacula - Web Bacula - web interface of a Bacula backup system
Owners: tim4dev
Branches: F-11 F-12 EL-5
InitialCC:

Запросы на пакеты для F-(X-2) версий федоры , если версия F-X уже выпущена не будут приняты. Например, если уже выпущен релиз Fedora 12, то запрос на пакет для Fedora 10 не принимается.

Смотреть очередь запросов на CVS

Пришли письма от From: Fedora PackageDB <pkgdb@fedoraproject.org> :

kevin added a Fedora 12 branch for webacula
kevin added a Fedora 11 branch for webacula
kevin added a Fedora EPEL 5 branch for webacula

/pkgdb/packages/name/webacula

Теперь нужно импортировать пакет в CVS.

Импорт в CVS

Создать отдельный каталог

mkdir webacula.cvs

Можно запустить ssh-add прежде чем делать любые операции в CVS. Это спасет вас от необходимости вводить пароль ключа для каждой операции. Пароль будет запомнен до завершения сеанса или перезагрузки.

ssh-add 

fedora-cvs webacula

cd webacula

./common/cvs-import.sh PATH_TO_SRPM

Шаг. 9 Импорт вашего srpm

Правильнее так (см. также New Package Process, п.9):

  ./common/cvs-import.sh -m "Initial import (#nnnnnn)." nameofmy.src.rpm

где nnnnnn номер вашего package-review-бага в Bugzilla.

Это будет импорт в ветку devel

Исходный тарбол не хранится в CVS, а находится где-то в другом месте.

Вы также захотите сделать дополнительный импорт, например,

./common/cvs-import.sh -m "Initial import (#nnnnnn)." -b F-11 PATH_TO_SRPM

где nnnnnn номер вашего package-review-бага в Bugzilla.

cd devel
cvs update

Шаг. 10 Теперь надо импортировать ваш пакет в остальные бранчи.

Самый быстрый способ - скопировать ваш .spec, патчи из devel/ в каждый бранч.

Проверьте наличие Makefile и скопируйте его, если необходимо. После этого

cvs add
cvs commit

build

Шаг. 11 Сделать тэг для ваших веток. Перед тем как бранч будет построен в Fedora Package buildsystem, файлы в нем д.б. тэгированы. Когда вы успешно сделали все коммиты в каждом бранче, идите в каталог бранча и

make tag

Вы должны увидеть тег ветки с версией и релизом из spec-файла. Вам необходимо тэгировать все бранчи, которые вы хотите построить. Если вы только что импортировали SRPM, то вам не нужно делать тэги, cvs-import.sh сделает это за вас.

Шаг 12. Запрос на builds

См. также про koji

Для каждого тэгированного бранча для которого вы хотите запросить build, идите в каталог бранча (например, cd F-11/) и запустите:

make build

Если все пойдет хорошо, то бранч должен стать в очередь билдинга, пакет будет построен, и все готово!

Если пакет не построился, сборочная система отправит вам емайл, чтобы сообщить о неудаче и линк к логам. Закоммитите какие-либо необходимые изменения в CVS, измените в Spec номер релиза, retag бранча, и запросите новый build.

Шаг 13: закройте Bugzilla баг (при условии, что пакет построен успешно). Вы должны закрыть его как NEXTRELEASE.

Шаг 15: Добавьте пакет в comps.xml, если необходимо. Так что он может быть выбран во время установки и включен в группы пакетов которые обрабатывает Yum.

См. также Cvs Faq где есть инструкции для создания новых релизов.

Скопировать spec и файл sources в другие бранчи

cvs add webacula.spec
cvs diff -u
cvs -m "Initial commit" commit

make tag

# или, если будет ругаться, что такой тэг уже есть
TAG_OPTS=-F make tag   # такое не приветствуется, в дальнейшем лучше
                       # изменить номер spec и сделать новый тэг


# чисто для проверки, что все в порядке
make srpm


make build
</<pre>




===make update===

[[PackageMaintainers/UpdatingPackageHowTo]]

Заключительный этап
<pre>
make update

Будет предложено ввести описание. Укажите

  type=newpackage
  request=testing
  bugs=<здесь № бага Review Request (цифра)>
  notes=<укажите описание пакета, скопируйте из  %description SPEC-файла>

После сабмита, Bodhi автоматически сделает запрос чтобы ваше обновление было протолкнуто в updates-testing. Если вы считаете, что тестирование не нужно для обновления, вы можете протолкнуть его прямо в стабильный репо обновлений Fedora.

Обратите внимание, что для обновлений безопасности есть несколько иной процесс.

Release Engineer вручную подпишет и протолкнет обновление.

После проталкивания в testing, у людей есть возможность обновлять карму +1/-1 вашего обновления пакета. Если ваше обновление достигает карма 3, оно автоматически будет протолкнуто в stable. Аналогично, если она достигает -3, оно будет автоматически unpushed. Если обновление не получает достаточной обратной связи для автоматического проталкивания в stable, вам придется засабмитить его в качестве финального обновления самого себя. Это можно легко сделать с параметром командной строки, или с веб-интерфейсом.

Затем вы будете уведомлены, когда ваше обновление попадет в stable. Бодхи закроет все тикеты связанные с ошибками и отправит объявление в fedora-package-announce рассылку.

На данный момент, ваше обновление официально выпущено!

Peter Lemenkov: когда выполнят твой запрос и переместят его в updates-testing, то там будет кнопочка "mark as stable"

Search

Как стать mantainer'ом пакета в Fedora. Конспект

Contents

Предисловие

Начало

Настройка системы

Имена

Pre-Release

Snapshot packages

Создание SPEC

секция %install

Сборка

Тестирование

koji

Review Request

Спонсор

CVS

Импорт в CVS

build