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

Предисловие

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

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

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

Начало

Источники:

1. Join the package collection maintainers
2. How to create an RPM package
3. Building Packages Guide
4. Packaging:Guidelines
5. Packaging:NamingGuidelines
6. New package process for existing contributors

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

• When Sally met Eddie: The Fedora package story
• CVS access for package maintainers
• Using CVS FAQ for package maintainers
• Использование ssh-agent от SSH1 и OpenSSH

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

• 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

См. также :

1. RPM Guide (by Eric Foster-Johnson)
2. Red Hat RPM Guide - русский перевод (Влад Горелецкий)
3. Сборка пакетов. Глава 1. RPM. Часть 2. Подготовка к сборке и обзор 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.