When a package reaches the end of its useful life, the following procedure will let other people -- and automated processes! -- know both not to expect any more releases, and why it was removed. The process is called retirement.
Please execute the following steps in the order indicated.
If the package is being replaced by some other package, ensure that the Obsoletes/Provides tags are properly set by the new package, see Renaming/Replacing Guidelines.
fedpkg retire DESCRIPTION in all branches that need to be retired starting with the oldest branch (e.g. retire on f21 before you retire on master)
DESCRIPTIONparameter should explain why the package was retired, good messages are:
Obsoleted by bar
Renamed to bar
- The command will remove all files from the branch, add a file name
dead.packagecontaining the description and push the changes. Starting with fedpkg 1.13 it will also retire the package in package DB.
git rmall files in the other branches only if there are special factors at work, like licensing issues, or package being removed completely from Fedora.
Ensure that the package is marked as retired in the package database system. This should happend automatically with fedpkg 1.13 and newer if you provide your FAS credentials. If it failed, you can retire the packge in the web interface or with the following command:
pkgdb-cli orphan --retire PACKAGENAME devel
- After the package was retired in package DB, you will not be able to commit changes to GIT unless you are a provenpackager. Therefore clean up GIT first.
develto the respective branch
- Start with the oldest branch
Remove the package from comps if it is listed.
Remove the package from any spin kickstart file
Upstream Release Monitoring
Remove the package from Upstream_release_monitoring if it is listed.
To keep retired packages from being pushed to the mirrors, they need to be blocked in koji. This should happen automatically within a short time for Fedora Branched and Rawhide. If it did not happen or for EPEL please file a
ticket for rel-eng (component
koji) asking the package from the appropriate collections in which it is retired.
- Use one ticket for all packages you retired at once, do not open one ticket for each package if you retired several packages.
- Use the
epelcomponent for EPEL packages
- You check whether a package is blocked in koji, e.g. for the package
currythere should the a entry with
[BLOCKED]for each branch the package was retired in. It is enough for a package to be retired in an older tag to be also blocked in a newer tag due to inheritance:
$ koji list-pkgs --show-blocked --tag f21 --package curry Package Tag Extra Arches Owner ----------------------- ----------------------- ---------------- --------------- curry f20 gemi [BLOCKED]
Note that you can use this process for EPEL as well with a few differences:
- You can remove the package from any EPEL branch whether or not it has been released.
- The component for the rel-eng ticket is
For example, if your package has been added to base RHEL in RHEL-6.4 then perform the steps above but use the
el6 branch instead of
master. When you open your rel-eng ticket to have the package blocked, use component
epel instead of