#152 Consider obsoleting in main retirement steps
Merged by oturpe. Opened by oturpe.
fedora-docs/ oturpe/package-maintainer-docs retirement-obsoleting  into  main

Download 152.patch

Previously, consideration for obsoleting the newly retired package was
only given almost at the end of the Package Retirement Process page,
having both EPEL considerations and unretirement instructions before
that section. Make it more obvious that obsoleting should be considered
every time a package is retired, by changing that to a step within the
main retirement steps.

Also, move the reference to the related, but different process of
renaming or replacing a package to the first, general section, rather
than hiding it within the obsoleting considerations.

This change was motivated by this mailing list thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OOFDTAWZE2H7INXNQLW7VIONBKHNAUVZ/

The documentation should actually instead document the agreed-upon policy, which is that packages should be added to fedora-obsolete-packages only if having those packages installed breaks something, e.g., prevents upgrading some other package due to broken dependencies, or causes a file conflict with some other package. Being retired is by itself not a reason to forcefully remove a package that users may depend on from their systems.

The documentation should actually instead document the agreed-upon policy, which is that packages should be added to fedora-obsolete-packages only if having those packages installed breaks something [...]

This is what I tried to say here (I am not trying to change any existing process here, just write it down better):

If this is not desired, such as if there are upgrade path issues or security concerns,

Is the issue with the verb "to desire"? I can replace the first part with "If this causes issues, such as ..." or similar, if that is more acceptable to you.

Or I can leave the previous wording, where there was no generic clause at all, just plain "if there are upgrade path issues or security concerns". I added the generic clause, because there are often foreseen situations that do not fit any of the previously imagined situations, and I think it is clear that a packager can obsolete a package if not doing so would lead to trouble.

By the way, while working on this, I tried to find the decision that retired packages should not be obsoleted without specific reason, so I could link there, but could not find anything. FESCo's Policy for Orphan and Retired Packages does not say anything about that. Is it just oral tradition at this point?

This is unfortunately pretty common in Fedora, that something gets discussed on the mailing list, a consensus is reached, but then not documented anywhere. I suspect some details were also lost in various documentation migrations between different wiki sections and from the wiki to docs.fp.o.

This is just a cleanup that moves the text around to make it easier to grok. We can changes to what the text says separately.

rebased onto 2796a04f70a99b9350b9eb7e326c0e5f01615199

Since the discussion has winded down, I just changed desired to acceptable and will merge this now.

rebased onto 131d0b840bf30d89c2f8031e8d51f72abf543e9f

Pull-Request has been merged by oturpe

  • For handing such situation, see

"For handling such situations, see"

Metadata