How to remove a package at end of life

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(update for git)
(add link to wiki page about unretirement)
(26 intermediate revisions by 11 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 steps will let other people -- and automated processes! -- know both not to expect any more releases, and why it was removed.  The process is simple.
+
  
For this example, we'll remove the package ''foo''.
+
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.
  
# 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]].
+
== Procedure ==
# Add a <code>dead.package</code> file to git in affected <code>foo</code> branches (usually <code>master</code> only).  The contents of this file should briefly explain where this package went:  'Obsolete package.', 'Renamed to bar' or the like.
+
{{admon/warning|Valid branches to retire a package|Only retire packagaes Branched until the [[Schedule|Final Change Deadline]], Rawhide (master) and EPEL branches (el5, el6).}}
# <code>git rm</code> all the other files in the <code>foo</code> branches that you added <code>dead.package</code> to. This should help make it clearly obvious what's going on here. It's not necessary to remove the files in other branches, unless there are other factors at work.  (e.g., licensing issue, package being removed completely from Fedora.)
+
Please execute the following steps in the order indicated.
# Remove the package from [[PackageMaintainers/CompsXml| comps]]  if it is listed.
+
 
# 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. There is also a Wiki list of [[PackageMaintainers/RetiredPackages | Retired Packages]] you can update if you choose, but it is now considered mostly obsoleted by the package database system.
+
=== RPM ===
# File a [https://fedorahosted.org/rel-eng/newticket ticket] for rel-eng asking the package to be blocked from the appropriate collections in which it is retired.
+
If the package is being replaced by some other package, ensure that the Obsoletes/Provides tags are properly set by the new package, see [[Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages|Renaming/Replacing Guidelines]].
 +
 
 +
=== GIT ===
 +
Run <code>fedpkg retire DESCRIPTION</code> in all branches that need to be retired starting with the oldest branch (e.g. retire on f21 before you retire on master)
 +
 
 +
==== 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. Starting with fedpkg 1.13 it will also retire the package in package DB.
 +
* <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.
 +
 
 +
=== Package DB ===
 +
Ensure that the package is marked as retired in [https://admin.fedoraproject.org/pkgdb 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
 +
 
 +
==== Remarks ====
 +
* After the package was retired in package DB, you will not be able to commit changes to GIT unless you are a [[Provenpackager policy|provenpackager]]. Therefore clean up GIT first.
 +
* Change <code>devel</code> to the respective branch
 +
* Start with the oldest branch
 +
 
 +
=== 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://fedorahosted.org/spin-kickstarts/ spin kickstart file]
 +
    git clone ssh://git.fedorahosted.org/git/spin-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 should happen automatically within a short time for Fedora Branched and Rawhide. If it did not happen or for EPEL please file a
 +
[https://fedorahosted.org/rel-eng/newticket ticket] for rel-eng (component <code>koji</code>) asking the package from the appropriate collections in which it is retired.
 +
 
 +
==== Remarks ====
 +
* 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 <code>epel</code> component for EPEL 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 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 <code>epel</code> rather than <code>koji</code>.
 +
 
 +
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>.  When you open your rel-eng ticket to have the package blocked, use component <code>epel</code> instead of <code>koji</code>.
 +
 
 +
== Unretire a Package ==
 +
See [[Orphaned_package_that_need_new_maintainers]]
  
 
[[Category:Package Maintainers]]
 
[[Category:Package Maintainers]]
 +
[[Category:Packaging guidelines]]

Revision as of 18:39, 1 September 2013

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.

Contents

Procedure

Warning (medium size).png
Valid branches to retire a package
Only retire packagaes Branched until the Final Change Deadline, Rawhide (master) and EPEL branches (el5, el6).

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 branches that need to be retired starting with the oldest branch (e.g. retire on f21 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.

Package DB

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

Remarks

  • 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.
  • Change devel to the respective branch
  • Start with the oldest branch

Comps

Remove the package from comps if it is listed.

Spins

Remove the package from any spin kickstart file

   git clone ssh://git.fedorahosted.org/git/spin-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 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.

Remarks

  • 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 epel component for EPEL 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 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 epel rather than koji.

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

Unretire a Package

See Orphaned_package_that_need_new_maintainers