From Fedora Project Wiki

(fedpkg retire already remove all files)
(55 intermediate revisions by 22 users not shown)
Line 1: Line 1:
<!-- page was renamed from Extras/PackageEndOfLife
+
{{autolang|base=yes}}
-->
 
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 simple.
 
  
 +
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.
 +
 +
See [[Policy for Orphan and Retired Packages]] for an overview of when to orphan and when to retire a package.
 +
 +
== 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 (epel7, epel8).
 +
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.
  
# Make sure the package is properly Obsoleted/Provided by something '''if''' it is being replaced, see [[Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages|Renaming/Replacing Guidelines]]. If not, go on to the next step.
+
=== RPM ===
# Run <code>fedpkg retire MSG</code>. This will recursively remove all files, then add a <code>dead.package</code> file to git.  Do it for all affected package branches (usually <code>master</code> only, but also the branched release if it has not yet released). The MSG parameter is a message which should briefly explain where this package went ('Obsolete package', 'Renamed to bar' or the like) and will be written in the dead.package file.
+
If the package is being replaced by some other package, ensure that the Obsoletes/Provides tags are properly set by the new package, see [https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages Renaming/Replacing Guidelines].
# <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.
+
 
# Remove the package from [[How_to_use_and_edit_comps.xml_for_package_groups| comps]]  if it is listed.
+
=== GIT ===
# Mark the package as "retired" in [https://admin.fedoraproject.org/pkgdb the package database system]: log in with your FAS credentials, go to the page for your package, and click the '''Retire package''' button for each branch on which you are retiring the package. Do '''not''' execute this step if you don't have already completed steps 2 and 3, otherwise you will have to ask a [[Provenpackager policy|provenpackager]] to perform those steps for you.
+
Run <code>fedpkg retire DESCRIPTION</code> in all non-stable Fedora branches and EPEL
# File a [https://fedorahosted.org/rel-eng/newticket ticket] for rel-eng (component koji) asking the package to be blocked from the appropriate collections in which it is retired.
+
branches, if applicable. The retiring needs to start with the oldest branch
# Optionally, you can update the Wiki list of [[PackageMaintainers/RetiredPackages|retired packages]], but it is now considered mostly obsoleted by the package database system.
+
(e.g. retire on f31 before you retire on rawhide)
 +
 
 +
 
 +
==== Remarks ====
 +
* The <code>DESCRIPTION</code> parameter should explain why the package was retired, good messages are:
 +
** <code>Obsoleted by bar</code>
 +
** <code>Renamed to bar</code>
 +
* The command will remove all files from the branch, add a file name <code>dead.package</code> containing the description and push the changes.
 +
* 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.
 +
 
 +
=== Comps ===
 +
Remove the package from [[How_to_use_and_edit_comps.xml_for_package_groups| comps]]  if it is listed.
 +
 
 +
=== Spins ===
 +
Remove the package from any [https://pagure.io/fedora-kickstarts 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.
 +
 
 +
{{admon/note|Use the Flag button|Currently, regular users can't delete a project from [[Upstream_release_monitoring]]. To delete a project, one must click on the Flag button and use the flagging form to request that the project be deleted.}}
 +
 
 +
 
 +
=== Koji ===
 +
To keep retired packages from being pushed to the mirrors, they need to be blocked in koji. This will happen during the next compose (for rawhide, the branched release and for EPEL). If the package was not blocked automatically after two days, please file a
 +
[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 ====
 +
* Please wait two days before opening a ticket to allow for a compose to happen and then the mirrors to be updated.
 +
* 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 <code>curry</code> there should the a entry with <code>[BLOCKED]</code> 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:
 +
 
 +
<pre>
 +
$ koji list-pkgs  --show-blocked --tag f21 --package curry
 +
Package                Tag                    Extra Arches    Owner
 +
----------------------- ----------------------- ---------------- ---------------
 +
curry                  f20                                      gemi            [BLOCKED]
 +
</pre>
 +
 
 +
== 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 <code>el6</code> branch instead of <code>master</code>.
 +
 
 +
== 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 [https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages packaging guidelines] 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.
 +
 
 +
If the retired package is not obsoleted by some replacement package, please consider adding your package to [https://src.fedoraproject.org/rpms/fedora-obsolete-packages/ fedora-obsolete-packages].
 +
 
 +
== Completely Removing a Package ==
 +
 
 +
In rare cases, such as when licensing issues are discovered,
 +
it may be necessary to completely remove a package from Fedora.
 +
This differs from normal retirement
 +
in that the package is removed also from stable and end-of-life releases.
 +
Complete removal is done as follows:
 +
 
 +
# Follow the [[#Procedure|procedure for normal removal]].
 +
# Additionally, retire the package in '''all''' dist-git branches. Since <code>fedpkg retire</code> refuses to work on stable branches, simulate it with the following:
 +
#:<pre>
 +
#:: $ DESC="my description"; git rm -r . && echo "$DESC" > dead.package && git add dead.package && git commit -m "$DESC"</pre>
 +
# Consider if the package should be added fedora-obsolete-packages for each branch.
 +
 
 
[[Category:Package Maintainers]]
 
[[Category:Package Maintainers]]

Revision as of 11:16, 14 July 2021

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.

See Policy for Orphan and Retired Packages for an overview of when to orphan and when to retire a package.

Procedure

Warning.png
Retire only in development/EPEL branches!
Do not retire packages in other branches than Branched (until the Final Freeze), Rawhide (master) and EPEL branches (epel7, epel8). 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.

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 f31 before you retire on rawhide)


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.
  • 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.

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.

Note.png
Use the Flag button
Currently, regular users can't delete a project from Upstream_release_monitoring. To delete a project, one must click on the Flag button and use the flagging form to request that the project be deleted.


Koji

To keep retired packages from being pushed to the mirrors, they need to be blocked in koji. This will happen during the next compose (for rawhide, the branched release and for EPEL). If the package was not blocked automatically after two days, please file a ticket for release engineering and mention the package name and the branch the package needs to be blocked.

Remarks

  • Please wait two days before opening a ticket to allow for a compose to happen and then the mirrors to be updated.
  • 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 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.

If the retired package is not obsoleted by some replacement package, please consider adding your package to fedora-obsolete-packages.

Completely Removing a Package

In rare cases, such as when licensing issues are discovered, it may be necessary to completely remove a package from Fedora. This differs from normal retirement in that the package is removed also from stable and end-of-life releases. Complete removal is done as follows:

  1. Follow the procedure for normal removal.
  2. Additionally, retire the package in all dist-git branches. Since fedpkg retire refuses to work on stable branches, simulate it with the following:
    $ DESC="my description"; git rm -r . && echo "$DESC" > dead.package && git add dead.package && git commit -m "$DESC"
  3. Consider if the package should be added fedora-obsolete-packages for each branch.