Как стать 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