Добавляем пакет в главный репозиторий Fedora

В данном HOWTO мы подробно рассмотрим как добавить новый пакет в главный репозиторий одного из самых популярных дистрибутивов GNU/Linux — Fedora, а также поддерживать его в актуальном состоянии.

Введение

Главный репозиторий дистрибутива Fedora уже содержит большое количество пакетов, но иногда нужного нам в нём ещё нет. В таком случае мы можем либо создать свой собственный репозиторий например на Fedora COPR, либо инициировать процедуру добавления нового пакета в главный репозиторий.

Большинство людей не доверяют личным репозиториям других пользователей, поэтому вариант с главным, на наш взгляд, будет лучшим.

Регистрация в системе

Для того, чтобы у нас появилась возможность предложить новый пакет на рассмотрение, необходимо зарегистрироваться в Bugzilla, а также создать FAS-аккаунт:

  1. регистрируем FAS-аккаунт, выбрав пункт New Account;
  2. в настройках FAS-аккаунта читаем и принимаем CLA соглашение;
  3. регистрируемся в Bugzilla на тот же адрес электронной почты, что и использована для FAS-аккаунта;
  4. подтверждаем регистрацию обоих аккаунтов посредством перехода по ссылке, которая была отправлена на электронную почту.

У нас появился FAS-аккаунт и доступ к баг-трекеру.

Создание пакета

Теперь мы должны создать RPM-пакет. Для этого сначала следует внимательно изучить данные гайдлайны:

Создаём SPEC-файл согласно вышеописанных гайдлайнов и убеждаемся в том, что он корректно собирается для всех платформ. Для этого лучше всего использовать личный COPR репозиторий или черновую сборку в Koji. Также следует обязательно убедиться, что пакет не содержит ничего запрещённого.

Создание заявки на добавление

Все пакеты в Fedora должны проходить достаточно строгий и долгий процесс package review, дабы исключить возможность появления в репозиториях вредоносного кода, а также некорректно составленных пакетов. Каждый новый мейнтейнер должен заручиться поддержкой (быть «спонсированным») от другого действующего мейнтейнера проекта Fedora.

Итак, если у нас есть правильно составленный SPEC и SRPM-файл, мы можем начать процесс подачи заявки:

  1. в Bugzilla заполняем форму. Здесь нужно подробно описать проект (на английском языке), добавить ссылки на апстрим, SPEC и SRPM файлы, а также указать лицензию проекта и свой логин в системе FAS. SRPM файл должен быть доступен по прямой ссылке (файлообменники не пройдут);
  2. отправляем заявку на рассмотрение;
  3. т.к. у нас ещё нет поручительства от другого мейнтейнера, добавим в качестве блокируемого бага FE-NEEDSPONSOR, что означает, что нам нужен «спонсор», т.е. поручитель;
  4. ожидаем рассмотрения и начала процесса package review;
  5. если в процессе будут найдены ошибки, либо высказаны конструктивные предложения, вносим изменения в наш SPEC;
  6. ожидаем окончательного одобрения от ревьювера (флаг fedora-review заявки изменится на fedora-review+).

Вместо простого ожидания лучшим решением будет заинтересовать других мейнтейнеров в добавлении данного пакета в репозиторий в списках рассылки, либо на официальном IRC канале.

Запрашиваем создание пакета

При успешном окончании процесса package review, необходимо создать заявку на добавление нового пакета непосредственно в репозиторий при помощи утилиты fedpkg.

Откроем в браузере Pagure и создадим токен (его следует создавать именно на Pagure, а не в Fedora SCM) для работы fedpkg (SettingsAPI KeysCreate new key). При создании следует выбрать лишь опцию Create a new ticket в разделе ACLs.

Создадим каталог для хранения настроек, а также пользовательский файл конфигурации:

mkdir -p ~/.config/rpkg
touch ~/.config/rpkg/fedpkg.conf

Откроем файл ~/.config/rpkg/fedpkg.conf в любом текстовом редакторе и добавим следующее содержимое:

[fedpkg.pagure]
token = YOUR_API_KEY

Здесь YOUR_API_KEY — полученный от Pagure токен доступа.

Запросим создание нового пакета:

fedpkg request-repo --namespace rpms --monitor monitoring package_name XXXXXX

Вместо XXXXXX следует указать номер тикета в RHBZ с успешно завершённым package review, а package_name — название будущего пакета. Также следует добавить описание и URL апстрима для системы мониторинга.

Теперь сразу запросим создание веток для всех поддерживаемых дистрибутивов:

fedpkg request-branch --namespace rpms --repo package_name --all-releases

Подготовка к загрузка пакетов

По окончании процедуры создания пакета, необходимо установить пакет fedora-packager, который содержит всё необходимое для мейнтейнера пакетов:

sudo dnf install fedora-packager

Настроим Git клиент, прописав в нём своё настоящее имя и адрес электронной почты, который зарегистрирован в Bugzilla и FAS аккаунте:

git config --global user.name "Your Name"
git config --global user.email [email protected]

Сгенерируем SSH ключ и пропишем его в настройках нашего FAS-аккаунта (укажем тот же адрес электронной почты в качестве комментария):

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Открытый ключ будет храниться в файле ~/.ssh/id_rsa.pub. Обязательно зададим сложный пароль, используемый для шифрования закрытого ключа.

Вход в систему через Kerberos

Войдём в Fedora System при помощи Kerberos:

kinit [email protected]

Здесь вместо username следует указать логин своего FAS-аккаунта в нижнем регистре. Домен же, наоборот, следует указывать в верхнем регистре.

Будет запрошен пароль от FAS-аккаунта. При успешном входе, мы сможем входить в любые сервисы инфраструктуры Fedora без ввода пароля, а также использовать консольные утилиты из работа мейнтейнера: koji, bodhi и т.д.

Kerberos-сессия истекает через 24 часа. По истечении этого времени, потребуется новый вход.

Загрузка пакетов в VCS и сборка

Теперь, наконец, мы можем загрузить наш пакет в Git и начать процесс сборки пакета в Koji.

Для начала загрузим рабочую копию репозитория нашего пакета (в наших примерах мы будем использовать имя пакета ourpackage):

fedpkg clone ourpackage

Перейдём в данный каталог:

cd ourpackage

Импортируем содержимое SRPM пакета:

fedpkg import /путь/к/srpm/пакету/ourpackage-1.0-1.fc26.src.rpm

Проверяем изменения и если всё верно, жмём Q для выхода. Если что-то импортировалось неправильно, то просто выполним откат к предыдущей ревизии:

git reset --hard

Коммитим наши изменения:

git commit -m "Initial import (#XXXXXX)."

Здесь вместо XXXXXX следует указать ID нашей одобренной заявки с package review.

Помещаем изменения на сервер:

git push

Запускаем сборку в Koji для rawhide:

fedpkg build

Собираем пакет для каждой версии дистрибутива

Теперь нам нужно распространить наши изменения из master во все остальные ветки (f26, f27 и т.д.).

Переключаемся на нужную ветку:

fedpkg switch-branch f26

Объединяем её с master:

git merge master

Если нужная ветка отсутствует и ранее мы запросили её, создадим самостоятельно:

git branch f26
git push --set-upstream origin f26

Выталкиваем изменения на сервер:

git push

Запускам сборку в Koji для данного дистрибутива:

fedpkg build

Отправляем пакет в главный репозиторий

По окончании сборки в Koji мы должны отправить пакет в главный репозиторий посредством Bodhi.

Снова перейдём в каталог нашего пакета:

cd our package

Переключимся на ветку нужного дистрибутива:

fedpkg switch-branch f26

Отправим последний результат сборки в Koji в Bodhi:

fedpkg update

Данный скрипт запросит логин и пароль от FAS-аккаунта, а затем предложит заполнить форму заявки на обновление. Большая часть параметров подтянется автоматически, поэтому просто проверяем и корректируем их, а затем подтверждаем отправку.

Через некоторое время пакет появится в -testing репозиториях, а по достижении определённой положительной кармы — в главном.

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

Для быстрого обновления релиза, а также обновления списка изменений лучше всего использовать скрипт rpmdev-bumpspec:

rpmdev-bumpspec -c "Updated to latest sources." ourpackage.spec

Для обновления пакета следует проделать то же самое: импортировать новый SRPM, отправить изменения на сервер, собрать для rawhide, объединить изменения в ветках с master, снова отправить изменения на сервер, собрать для всех актуальных версий, а затем выгрузить обновления в Bodhi.

2 commentary to post

  1. KT :

    Сколько ты ждал одобрения своих пакетов?

    Полгода. И ещё бы пришлось ждать столько же, если бы другой мейнтейнер не захотел самостоятельно добавить этот же пакет в репозиторий. Т.к. заявка на добавление пакета уже висела в BugZilla, он провёл процедуру package review и выступил поручителем.

Обсуждение закрыто.