Предисловие
Этот конспект я вел исключительно для собственных нужд. Поэтому этот текст не является руководством, это необходимо понять прежде всего - это краткий конспект. Вместо любых разъяснений даны ссылки на исчерпывающие материалы по теме, которые обновляются, как и принято в комьюнити, более сведущими специалистами. В этом тескте также нет правильных переводов терминов.
Конспект написан по причине того, что в федора-вики много информации по теме, и, вместе с тем, некоторые особенности освещены слабо. По крайней мере, это вызвало у меня, как у ньюба, затруднения. Но, в целом, повторюсь, информации по данной теме в федора-вики много, англоязычной, естественно.
Автор выражает надежду, что изложенная информация будет полезна для успешного старта.
Начало
Источники:
- Join the package collection maintainers
- How to create an RPM package
- Building Packages Guide
- Packaging:Guidelines
- Packaging:NamingGuidelines
- 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
Настройка системы
# yum groupinstall "Development Tools" # yum install rpmdevtools
Создать отдельного юзера под которым будут собираться пакеты:
# /usr/sbin/useradd makerpm
Создать дерево каталогов, необходимое для сборки
$ rpmdev-setuptree
Имена
Допустимые символы для именования пакета
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
См. также :
- RPM Guide (by Eric Foster-Johnson)
- Red Hat RPM Guide - русский перевод (Влад Горелецкий)
- Сборка пакетов. Глава 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).
