From a64cfa5215ea86770ceb3542fb067afb1024b46b Mon Sep 17 00:00:00 2001 From: Zbigniew Jędrzejewski-Szmek Date: Oct 11 2021 19:52:50 +0000 Subject: Change MAY to SHOULD for fedora-obsolete-packages inclusion The logic that we use in Fedora has changed: in the past we were perfectly happy with users having to do various magical incantations during upgrades. Nowadays we expect upgrades to go smoothly. If a package causes a "dependency issues which interfere[s] with upgrades or [is] otherwise harmful" we expect the package to be removed, period. Thus, the recommendation is changed to SHOULD. (I would go for "MUST", because *somebody* will have to do this, it's not clear *who*. Sometimes it'll be the person retiring the package, but most often it'll just be somebody who notices that the upgrade path is broken. Those events are often separated in time. Also, we can't/don't want to block package retirement. So it's "a packager SHOULD", not "the package MUST".) Also change the section title, because people might be looking how to obsolete a package, but the title suggested that the section is about renames only. --- diff --git a/guidelines/modules/ROOT/pages/index.adoc b/guidelines/modules/ROOT/pages/index.adoc index 9517545..723c4f8 100644 --- a/guidelines/modules/ROOT/pages/index.adoc +++ b/guidelines/modules/ROOT/pages/index.adoc @@ -2041,7 +2041,7 @@ These have the effect of making the appropriate changes immediately upon package There are specific guidelines for handling tmpfiles.d configurations and directories (in /run and /run/lock): xref:Tmpfiles.d.adoc[Tmpfiles.d]. [#renaming-or-replacing-existing-packages] -== Renaming/Replacing Existing Packages +== Renaming/Replacing or Removing Existing Packages NOTE: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/[Package Renaming Process] should be followed when renaming an existing package. @@ -2060,7 +2060,7 @@ If a package supersedes/replaces an existing package without being a sufficientl CAUTION: *Take `+%{?dist}+` into account*: When deciding what $obsEVR should be, remember that it needs to be higher than the previous `Release:` with `+%{?dist}+` expanded. Example: if the package previously had `+Release: 4%{?dist}+` the release in $obsEVR should be at least 5. -If retired packages need to be removed from end user machines because they cause dependency issues which interfere with upgrades or are otherwise harmful, a packager MAY request that `+Obsoletes:+` be added to `+fedora-obsolete-packages+`. Simply file a bugzilla ticket https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=fedora-obsolete-packages[here]. Please include information on which packages need to be obsoleted, the exact versions which need to be obsoleted, and the reasons why they cannot be allowed to remain installed. +If retired packages need to be removed from end user machines because they cause dependency issues which interfere with upgrades or are otherwise harmful, a packager SHOULD request that `+Obsoletes:+` be added to `+fedora-obsolete-packages+`. Simply file a bugzilla ticket https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=fedora-obsolete-packages[here]. Please include information on which packages need to be obsoleted, the exact versions which need to be obsoleted, and the reasons why they cannot be allowed to remain installed. If the obsoleted package had an Epoch set, it must be preserved in both the `+Provides:+` and `+Obsoletes:+`. For example, assume foo being renamed to bar, bar is compatible with foo, and the last foo package release being foo-1.0-3%\{?dist} with Epoch: 2. The following should be added to bar (and similarly for all subpackages as applicable):