Fedora Package Lifecycle notes

This is NOT official documentation
This page describes the packaging lifecycle from one person's own experience. Use the official documentation instead

Fedora package lifecycle

A package goes through the following states from its creation until its part of a release. At each state you can take the listed steps to move it to the next state.

1. Unknown
   • This procedure tries to find out where in its lifecycle a package is by searching for lifecycle states in reverse order:
   • Check whether a package exists already in a release
   • Check whether the package has (non-scratch) Koji builds https://apps.fedoraproject.org/packages/<your-package-name>
   • Check whether a SCM repository exists already https://admin.fedoraproject.org/pkgdb/package/<your-package-name>
   • Check whether a review request exists already
   • Check whether the package would be allowed at all
2. Not found
   • You can become a package maintainer and create a package yourself
   • Familiarize yourself with the official guidelines
   • Create a .spec file following the official guidelines above
   • Make sure that your package builds (using rpmbuild or preferably mock )
   • Check that your package meets the review guidelines
   • (optional) perform a Koji scratch build (this requires having a FAS account, but doesn't require sponsoring)
   • (optional) run fedora-review to get prepared for the review. The output doesn't have to be perfect, certain things may be safe to ignore. Discuss with your reviewer/sponsor if you are uncertain on what to do with the warnings reported.
3. Creating review request
   • Upload your spec and SRPM files to a public place (you can use your fedoraproject.org webspage if you are sponsored already , or some personal site otherwise)
   • Create a package review request . You'll need to have the following information at hand:
     • package name, short package description, full package description
     • Spec URL
     • SRPM URL
     • your FAS username
     • link to your Koji scratch build (optional)
     • if this is your first package block the FE-NEEDSPONSOR bug
4. Review requested: fedora-review is -
   • nobody is reviewing the package yet
   • be patient until you find a reviewer, they will set the fedora-review flag to ?
5. Under review: fedora-review is ?
   • a fedora packager is reviewing your package, be patient and solve any issues they find.
   • Increment the spec release version, add a changelog entry, and post the new spec, SRPM and (optionally) Koji URLs to bugzilla together with an explanation of what you changed.
   • iterate until the reviewer approves your package, at which point they will set the fedora-review flag to +
6. Approved: fedora-review is +
   • if this is your first package then find a sponsor, see becoming a packager
   • create a SCM admin request by setting the fedora-cvs flag to ? and using the exact template from the official documentation . You will need the following information at hand:
     • package name
     • short description
     • upstream URL
     • package owners (maintainer and co-maintainers)
     • branches: fedora and epel release branches that you want to target
     • list of FAS usernames receiving email regarding the package (probably just you unless package is co-maintained)
7. SCM repository requested: fedora-cvs flag is ?
   • wait for about a day, when an admin will set the fedora-cvs flag to +
8. SCM repository granted: fedora-cvs flag is +
   • at this point the repository should be created, and you can track the status at https://admin.fedoraproject.org/pkgdb/package/<your-package-name>
   • might take about an hour until your permissions are synchronized
   • use fedpkg to import the package, and push the changes
   • Test your commits: you are not allowed to force push your git branches, so take care at least run fedpkg local and fedpkg lint to check for problems before pushing any changes. Remember to bump the spec revision and add a changelog entry in the spec file each time
   • request a koji build for rawhide from your master branch with fedpkg build: koji will build for x86_64, i686 and armv7l.
   • You can access the build logs from the koji webinterface or cli.
   • you can use koji download-build to get the built package
   • some time later the package will show up on https://apps.fedoraproject.org/packages/<your-package-name>
9. Has koji build for rawhide
   • make sure to always request a build for rawhide (master branch) before pushing or requesting builds for other branches
   • read the update policy
   • once the Koji build succeeded and you've tested the package use fedpkg and merge master to your other branches, push your changes and request a koji build for each branch in turn
10. Has koji build for a (branched) fedora release
    • once the builds succeed and you've tested the package use 'fedpkg update' to request an update in Bodhi. You will need the following information:
      • package name
      • type is newpackage
      • request is testing
      • bug number of your review request (bodhi can auto-close when package is stable)
      • notes: new package
      • auto-karma at default settings
    • bodhi (?) will also trigger a build for s390 and s390x
    • your request will show up in bodhi as PENDING https://admin.fedoraproject.org/updates/<package-name>
11. Bodhi shows PENDING status for package
    • the package goes through PENDING -> TESTING -> STABLE for each fedora release independently. Note that rawhide builds must not be submitted to Bodhi, they should be available automatically after some time.
    • while in this state users cannot yum install or dnf install your package yet
    • a (human) release engineer manually signs and pushes packages from PENDING to TESTING almost daily
    • be patient, there might be an extra day or so delay when the package is being pushed
    • taskotron will run some automated tests on your package, posts its logs to bodhi and gives negative karma if it fails any tests
    • at some point it will start to get pushed "This update is currently being pushed to the Fedora N testing updates repository."
12. Bodhi shows TESTING status for package
    • in TESTING fedora users can see your package if they have the updates-testing repository enabled in yum or dnf (default enabled for Alpha releases, disabled for final releases): yum install --enablerepo="*-testing" <your-package-name> or dnf install --enablerepo="*-testing" <your-package-name>
    • any fedora user with a FAS account can provide feedback (karma)
    • package gets promoted to stable if it receives enough positive karma, or enough time passes (3 days for alpha/beta and 7 days for released branches)
    • it can also get rejected if it receives too much negative karma, at which point you have the fix the problems and submit a new spec revision that will become PENDING again
13. Bodhi shows STABLE status for package
    • users can now install your package as usual with yum install <yourpackage> or dnf install <yourpackage>

EPEL package lifecycle

TBD
where to get approval, what is the exact lifecycle for an EPEL package

1. • Read the EPEL policies

New packager

1. • Do not get discouraged by the large number of steps and be patient: some of them depend only on you (the packager) and take little time, other steps are outside your control and can take a long time to complete.
   • Create a bugzilla account
   • Create a FAS account
   • Login to FAS and sign the CLA, upload your public SSH key, and (optionally) your OpenPGP key
   • Consult the documentation
   • At this point you can submit your package review request
     • Make sure to block the FE-NEEDSPONSOR bug if you are not yet sponsored into the packager group (i.e. this is your first package)
   • Inform upstream that you are packaging their software
   • Join the relevant mailing lists
   • Send a self-introduction email
   • Get sponsored into the packager group (you will get an email when this is done)
   • Read the package maintenance guide