Процесс добавления нового пакета для новых участников

Следуйте Установка инструментов упаковщика.

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

Перед созданием пакета убедитесь, что программное обеспечение ещё не находится в репозитории Fedora:

Загрузите ваши SRPM и SPEC-файлы в Интернет так, чтобы другие могли их получить. Это может быть любое место, доступное по URL-адресу, но важно, чтобы файлы были доступны напрямую, а не скрыты за каким-либо сервисом, который заставляет людей ждать загрузки или перенаправляет через страницы с рекламой.

Рекомендуется использовать Copr. Он позволяет создавать репозитории с использованием src.rpm или spec-файла, которые затем можно предоставить проверяющим. Он также может создавать автоматические сборки из этих файлов и распространять результаты.

Сначала вам нужно войти в Copr, для этого вы можете использовать свою учётную запись Fedora.

Затем следуйте этому руководству для сборки проекта. На шаге "New Build" вам нужно загрузить исходный код; вы можете выбрать тот вариант, который вам больше подходит, но если у вас нет исходного кода, загруженного куда-либо ещё, вы можете выбрать опцию Upload и затем в разделе предоставления шага нажать кнопку Browse…​ для выбора файла. Теперь в следующем разделе вам нужно указать Chroots и другие параметры сборки; выберите хотя бы один chroot fedora-rawhide и настройте остальные параметры по необходимости.

После завершения сборки вы можете использовать следующие ссылки для процесса проверки:

Заполните форму проверки Bugzilla Fedora.

Процесс проверки подробно описан на странице Процесс проверки пакетов.

Проект Fedora предпочитает оставаться близким к вышестоящим проектам. Сообщите разработчикам, что вы упаковываете их программное обеспечение. Вы можете сделать это, отправив им электронное письмо с представлением и указанием запроса на проверку. Это создаёт основу для будущих диалогов. Они обычно сообщают о том, что их программное обеспечение теперь является частью Fedora, или могут захотеть сообщить вам о важных ошибках в существующем выпуске, будущих планах и т. д.

Следите за отчётом Bugzilla для вашего первого пакета. Вы должны получать уведомления об изменениях по электронной почте. Исправляйте все блокирующие проблемы, на которые указывают проверяющие.

Когда пакет ОДОБРЕН проверяющим, вы должны отдельно получить спонсорство члена, чтобы иметь возможность загружать и собирать свой пакет. Спонсорство не является автоматическим и может потребовать вашего дальнейшего участия другими способами, чтобы продемонстрировать ваше понимание рекомендаций по упаковке. Ключ к получению спонсорства — убедить существующего члена уровня спонсора в том, что вы понимаете и соблюдаете руководящие принципы и процессы проекта.

См. Как получить спонсорство в группе упаковщиков для получения дополнительной информации о процессе получения спонсорства.

Ваш спонсор может добавить вас в группу упаковщиков. Вы должны получить подтверждение спонсорства по электронной почте.

Перед продолжением синхронизируйте свою учётную запись, войдя в Fedora Package Sources с использованием своих учётных данных FAS.

If you are becoming a maintainer for a new package, instead of being a co-maintainer, use fedpkg to request a new git repository for your package. The sub-command is fedpkg request-repo which includes help text for setting up the distgit API token the command requires. When creating your API-key choose at least Read and write permissions for issue. You will probably want the token to have additional permissions to support other package-maintenance tasks. You must specify the repository name and review bug number. For example:

The request will be reviewed and processed automatically. After processing, you will have access to commit and build the package. In case the automation does not work, you can report the problem to Toddlers issue tracker.

fedpkg request-repo создаёт ветку только для Rawhide. Для запроса веток для других выпусков Fedora см. Запрос веток.

Вы можете получить свой репозиторий distgit сейчас, но перед этим рассмотрите возможность выполнить mkdir ~/fedora-scm ; cd ~/fedora-scm — так все ваши файлы будут находиться в одном каталоге. Также выполните ssh-add, чтобы вам не приходилось постоянно вводить пароль ключа.

Теперь вы готовы получить свой репозиторий distgit из SCM:

Обратитесь к Использованию Mock для тестирования сборки пакетов и Пробным сборкам в Koji для получения дополнительной информации о тестировании вашего пакета. Mock использует вашу локальную систему, а инструмент командной строки Koji использует сервер системы сборки Fedora.

Теперь, когда вы получили свой (пустой) репозиторий distgit с помощью fedpkg, перейдите в основную ветку репозитория:

Запустите fedpkg для импорта содержимого SRPM в SCM:

Очевидно, замените PATH_TO_SRPM на полный путь (не URL) к вашему утверждённому SRPM, а XXXXXX на номер ошибки проверки пакета.

Если ваш пакет использует autochangelog, указание номера ошибки, как описано, приведёт к тому, что система обновлений Fedora автоматически закроет ошибку, когда ваш пакет будет отправлен в стабильный репозиторий Rawhide.

Это импортирует, фиксирует и собирает только основную (Rawhide) ветку.

Если отправка завершается ошибкой с таким сообщением:

Тогда у вас нет необходимых прав для изменения этой ветки пакета. Перейдите на https://src.fedoraproject.org/rpms/PACKAGE_NAME, чтобы запросить эти права.

Для получения дополнительной информации об использовании системы сопровождения пакетов Fedora см. Руководство по сопровождению пакетов.

Ветки имеют вид f# (ранее F- и до этого FC-), main и т. д. Таким образом, f — это ветка для Fedora.

Чтобы сначала переключиться на ветку:

(например, f42)

Выполните слияние начального коммита из main (Rawhide), создавая идентичный коммит в ветке:

Отправьте изменения на сервер:

Соберите пакет:

Если есть другая ветка для работы, повторите шаги To switch to a branch и импортируйте и фиксируйте изменения для каждой ветки.

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

Если сборка не удастся, система сборки отправит вам электронное письмо с сообщением об ошибке и укажет на журналы. Зафиксируйте необходимые изменения в git, увеличьте номер выпуска в SPEC и запросите новую сборку.

Если это уместно для пакета, включите его в файлы "comps", чтобы его можно было выбрать во время установки и включать в операции с группами пакетов dnf. Дополнительную информацию см. в Как использовать и редактировать comps.xml для групп пакетов.