PackageMaintainers/ru/Как стать владельцем пакета

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

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

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

--Tim4dev 13:50, 6 November 2009 (UTC)

Начало
Источники:


 * 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
 * 1) yum groupinstall "Development Tools"
 * 2) yum install rpmdevtools

Создать отдельного юзера под которым будут собираться пакеты:
 * 1) /usr/sbin/useradd makerpm

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

Имена
Packaging:NamingGuidelines

Допустимые символы для именования пакета a--z A--Z 0--9 -._+

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

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

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

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

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

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

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

Пример для release candidate 1 См. также Software release life cycle для общего развития.
 * 1) define alphatag rc1

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
 * 1) пример

в %{buildroot}, обычно это /var/tmp/something

~/src/BUILDROOT/%{name}-%{version}-%{release}.i386 и создают подкаталоги в %{buildroot} если нужно.
 * 1) пример

Сборка
Быстрое тестирование: 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


 * 1) или

$ 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-packager-setup

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

$ koji build --scratch dist-f15 webacula-3.2.1-1.fc15.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 указать баг.

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

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

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

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

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

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

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-14 F-15 EL-5 InitialCC:

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

Пришли письма от  : 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.

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

ssh-add

fedpkg-clone webacula

cd webacula

fedpkg import PATH_TO_SRPM

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

Правильнее так (см. также New Package Process, п.9): git commit -a -m "Initial import (#nnnnnn)" git push где nnnnnn номер вашего package-review-бага в Bugzilla.

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

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

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

Перейдите в другую ветку (бранч) командой fedpkg switch-branch 

и выполните шаги из предыдущего пункта. (import, commit и push)

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

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

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

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

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

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

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

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

make update
PackageMaintainers/UpdatingPackageHowTo

Заключительный этап fedpkg 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"

Bodhi
Вместо "fedpkg update" можно юзать bodhi command-line interface или bodhi веб-интерфейс

Смотреть инфу по пакету (примеры) bodhi --new -R stable -b 529269 -t newpackage -u atorkhov cmospwd-5.0-1.fc12

bodhi -u tim4dev -m webacula-3.3-6.fc11 -m webacula-3.3-6.fc12

bodhi webacula

Окончание
Ч/з 2-е недели пришло письмо From: updates@fedoraproject.org Subject: [Fedora Update] [old_testing] webacula-3.3-6.fc11 To: tim4dev@fedoraproject.org Date: Fri, 06 Nov 2009 00:00:07 +0000 X-Mailer: TurboMail TurboGears Extension v.2.1

The update for webacula-3.3-6.fc11 has been in 'testing' status for over 2 weeks. This update can be marked as stable after it achieves a karma of 3 or by clicking 'Push to Stable'.

This is just a courtesy nagmail. Updates may reside in the testing repository for more than 2 weeks if you deem it necessary.

You can submit this update to be pushed to the stable repository by going to the following URL:

http://admin.fedoraproject.org/updates/request/stable/webacula-3.3-6.fc11

or by running the following command with the bodhi-client:

bodhi -R stable webacula-3.3-6.fc11

=
===================================================================    webacula-3.3-6.fc11

=
=================================================================== Update ID: FEDORA-2009-10550 Release: Fedora 11 Status: testing Type: newpackage Karma: 1 Notes: Webacula - Web Bacula - web interface of a Bacula backup system. : Supports the run Job, restore all files or selected : files, restore the most recent backup for a client, : restore backup for a client before a specified time, : mount/umount Storages, show scheduled, running and : terminated Jobs and more. Supported languages: : English, French, German, Portuguese Brazil, Russian. Submitter: tim4dev Submitted: 2009-10-16 12:38:47 Comments: tim4dev - 2009-10-16 12:38:49 (karma 0) This update has been submitted for testing

tim4dev - 2009-10-20 09:58:09 (karma 1) bodhi - 2009-10-21 00:34:27 (karma 0) This update has been pushed to testing

http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10550

Что дальше
Обновлять сопровождаемый пакет: Package_update_HOWTO

Новый пакет
Следующие пакеты добавлять по процедуре: PackageMaintainers/NewPackageProcess

Обновление пакета
Package update guidelines

Многие пользователи обновляют Fedora автоматически, поэтому крайне важно, чтобы обновление не причинило вреда или система внезапно не перестала работать.

Обновление с багфиксами как правило, должно быть сначала помещено в "testing" и оно затем попадет в "stable" после того, как наберет достаточо кармы в bodhi.

Новый релиз не обязательно должен быть pushed в release ветку. Rawhide является веткой разработки, куда можно проталкивать обновления перед тем как протолкнуть их в release ветку.

Fedora пользователи, которые не обновляются автоматически должны иметь возможность посмотреть (через PackageKit) описание обновлений, прежде чем решить, должны ли они ставить их. Поля Bugs и Notes (в бодхи) - это вся инфа, которая доступна юзерам при просмотре обновлений в PackageKit (но не %changelog в rpm).

Надо иметь в виду, что слишком подробное описание может быть столь же бессмысленно, как слишком короткое. Мантайнер должен иметь в виду, что не все пользователи Fedora имеют хороший канал в Интернет.