(→Remarks: fix list formatting) |
(→Koji: update rel-eng tracker) |
||
(10 intermediate revisions by 6 users not shown) | |||
Line 4: | Line 4: | ||
== Procedure == | == Procedure == | ||
{{admon/warning|Retire only in development/EPEL branches!|Do not retire packages in other branches than Branched (until the [[Schedule|Final Freeze]]), Rawhide (master) and EPEL branches (el5, el6, epel7).}} | {{admon/warning|Retire only in development/EPEL branches!|Do not retire packages in other branches than Branched (until the [[Schedule|Final Freeze]]), Rawhide (master) and EPEL branches (el5, el6, epel7). | ||
When you need to add package from EPEL to any RHEL release, only retire EPEL branch when package is released in that RHEL release.}} | |||
Please execute the following steps in the order indicated. | Please execute the following steps in the order indicated. | ||
Line 11: | Line 12: | ||
=== GIT === | === GIT === | ||
Run <code>fedpkg retire DESCRIPTION</code> in all branches | Run <code>fedpkg retire DESCRIPTION</code> in all non-stable Fedora branches and EPEL | ||
branches, if applicable. The retiring needs to start with the oldest branch | |||
(e.g. retire on f25 before you retire on master) | |||
==== Remarks ==== | ==== Remarks ==== | ||
Line 20: | Line 24: | ||
* <code>git rm</code> all files in the other branches '''only if''' there are special factors at work, like licensing issues, or package being removed completely from Fedora. | * <code>git rm</code> all files in the other branches '''only if''' there are special factors at work, like licensing issues, or package being removed completely from Fedora. | ||
* If you retired master before other older branches you want to retire, just continue with the older branches. It will still work, but will block the package in more Koji tags, because tag inheritance will not be used automatically then. | * If you retired master before other older branches you want to retire, just continue with the older branches. It will still work, but will block the package in more Koji tags, because tag inheritance will not be used automatically then. | ||
* Ignore any errors related to Package DB. The package state is not tracked in Package DB anymore and a future fedpkg update will remove Package DB support from fedpkg. | |||
=== Comps === | === Comps === | ||
Line 34: | Line 30: | ||
=== Spins === | === Spins === | ||
Remove the package from any [https:// | Remove the package from any [https://pagure.io/fedora-kickstarts spin kickstart file] | ||
git clone ssh://git. | fork fedora-kickstarts and check out your clone. commit any fixes and send in a Pull Request | ||
git clone ssh://git@pagure.io/path/to/fork/fedora-kickstarts.git | |||
=== Upstream Release Monitoring === | === Upstream Release Monitoring === | ||
Line 42: | Line 39: | ||
=== Koji === | === Koji === | ||
To keep retired packages from being pushed to the mirrors, they need to be blocked in koji. This will happen during the next Rawhide/Branched compose (also for EPEL). If it did not happen file a | To keep retired packages from being pushed to the mirrors, they need to be blocked in koji. This will happen during the next Rawhide/Branched compose (also for EPEL). If it did not happen file a | ||
[https:// | [https://pagure.io/releng/new_issue ticket] for release engineering and mention the package name and the branch the package needs to be blocked. | ||
==== Remarks ==== | ==== Remarks ==== | ||
Line 65: | Line 62: | ||
== Unretire a Package == | == Unretire a Package == | ||
See [[Orphaned_package_that_need_new_maintainers]] | See [[Orphaned_package_that_need_new_maintainers]] | ||
== Obsoleting Packages == | |||
While not strictly part of the process, please consider what will happen to systems which have the now-retired packages installed. Generally such packages will simply remain on the system as it is updated, becoming increasingly outdated. | |||
Please follow relevant packaging guidelines [[Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages|here]] if another package will be providing similar or identical functionality to the retired package, or if it is necessary that the package be removed from end-user systems on system updates. | |||
[[Category:Package Maintainers]] | [[Category:Package Maintainers]] | ||
Revision as of 19:23, 3 September 2017
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.
Procedure
Please execute the following steps in the order indicated.
RPM
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.
GIT
Run fedpkg retire DESCRIPTION
in all non-stable Fedora branches and EPEL
branches, if applicable. The retiring needs to start with the oldest branch
(e.g. retire on f25 before you retire on master)
Remarks
- The
DESCRIPTION
parameter 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.package
containing the description and push the changes. Starting with fedpkg 1.13 it will also retire the package in package DB. git rm
all files in the other branches only if there are special factors at work, like licensing issues, or package being removed completely from Fedora.- If you retired master before other older branches you want to retire, just continue with the older branches. It will still work, but will block the package in more Koji tags, because tag inheritance will not be used automatically then.
- Ignore any errors related to Package DB. The package state is not tracked in Package DB anymore and a future fedpkg update will remove Package DB support from fedpkg.
Comps
Remove the package from comps if it is listed.
Spins
Remove the package from any spin kickstart file fork fedora-kickstarts and check out your clone. commit any fixes and send in a Pull Request
git clone ssh://git@pagure.io/path/to/fork/fedora-kickstarts.git
Upstream Release Monitoring
Remove the package from Upstream_release_monitoring if it is listed.
Koji
To keep retired packages from being pushed to the mirrors, they need to be blocked in koji. This will happen during the next Rawhide/Branched compose (also for EPEL). If it did not happen file a ticket for release engineering and mention the package name and the branch the package needs to be blocked.
Remarks
- Please wait long enough before opening a ticket to avoid unnecessary work.
- Use one ticket for all packages you retired at once, do not open one ticket for each package if you retired several packages.
- You check whether a package is blocked in koji, e.g. for the package
curry
there 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]
EPEL
Note that you can use this process for EPEL as well with one difference:
- You can remove the package from any EPEL branch whether or not it has been released.
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
.
Unretire a Package
See Orphaned_package_that_need_new_maintainers
Obsoleting Packages
While not strictly part of the process, please consider what will happen to systems which have the now-retired packages installed. Generally such packages will simply remain on the system as it is updated, becoming increasingly outdated.
Please follow relevant packaging guidelines here if another package will be providing similar or identical functionality to the retired package, or if it is necessary that the package be removed from end-user systems on system updates.