Package Release Procedure


This page describes the package release procedure (e.g. RPMs for Fedora/EPEL). For the source code release and versioning procedure see Release_Procedure

Fedora/EPEL

Prerequisites

Read this Guide

How To Be A Fedora/EPEL Package Maintainer - this is a good step-by-step guide which tells you which accounts you need and which packages you need to install. It also has other useful information about Fedora systems, RPM, yum, etc.

Set up Accounts

Become a Package Maintainer

You will need a FAS account before you can be added to the package maintainers group. Unless you are adding a new package, you will want to be a Co-Maintainer How to become a Co-Maintainer. You will have to find someone who is a Sponsor to add you to the packager group in FAS How to sponsor a new contributor.

Install Software

Get the Packages

This will create a subdirectory called pkgname. fedpkg uses git under the covers, and you can mostly use regular git commands. One notable exception is git checkout - use fedpkg switch-branch instead.

Edit/Add Files

Usually changes will apply to multiple branches (e.g. a new release on rawhide/F18/F17). It’s best to work in the rawhide branch, then merge or cherry-pick your changes to other branches.

Build

For each branch:

You will receive email notification when the build is complete - if it fails, go back to Edit/Add Files - you will need to at least bump the Revision number in the .spec file, commit/cherry-pick/push, then Build again.

EPEL 6 - 389-ds-base

389-ds-base is not in EPEL6 or later because it is included in RHEL, and EPEL policy forbids it. We still provide builds for EPEL though, via the Fedorapeople Repos. These packages do not follow the regular fedpkg build/update procedure. Instead, it is entirely manual.

Submit the Build to Testing

For each branch:

Note: fedpkg update will start up vi editing a form. You can use this form for each branch. Instead of saving and exiting, first just save it, then save it under a name like update.save. When you do the next update in the next branch, delete the contents of the buffer, then load in your saved file, then edit the release and version.

After the update has been pushed, you will receive an email notifications from the koji/bodhi workflow, and when the package has been pushed to the Testing repositories.

Push the Update to Stable

You can monitor the state of the update in bodhi - Fedora Update System. There are a couple of ways to push the update to the Stable repositories.

Update Source Repo

If you did not already push the VERSION.sh commit and the version tag as in Release_Procedure, do so now. Once the build is out in the wild, you have no choice but to release another version from scratch.

Example fedpkg/git workflow

Here is a very simple sequence of operations:

fedpkg clone 389-ds-base
cd 389-ds-base
fedpkg switch-branch rawhide
vi 389* # edit Version, Release, add %changelog
fedpkg new-source /path/to/389-ds-base-VERSION.tar.bz2
fedpkg clog
fedpkg verrel
git commit -a -F clog
fedpkg switch-branch f18
git cherry-pick -x rawhide
fedpkg switch-branch f17
git cherry-pick -x f18
git push --dry-run
git push
fedpkg switch-branch rawhide
fedpkg build --nowait
fedpkg switch-branch f18
fedpkg build --nowait
fedpkg switch-branch f17
fedpkg build --nowait

# wait for the builds to complete - you will receive email notification

fedpkg switch-branch f18
fedpkg update
fedpkg switch-branch f17
fedpkg update
Last modified on 1 March 2024