On 15. 06. 20 21:47, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.
My general feedback:
+ I agree that removing retired and otherwise removed packages on release
boundary upgrade is a reasonable default (with possible opt out).
- I do not think that doing this via obsoletes is the best way to achieve that
goal. Already now, the situation is confusing to users wrt
fedora-obsolete-packages. (However I realize that this is something that can be
driven by a proposal like this easier than driving dnf system upgrade behavior
changes.)
- I do not want to maintain the information in the package metadata and keep it
up to date. Who does this? Note that releng does not follow the linked
sop_retire_orphaned_packages.rst at all. And even if we manage to get "fedpkg
retire" do the thing 100 % automatically, note that if a package gets removed
from Fedora N, and is obsoleted via fedora-obsolete-packages (or
fedora-retired-packages in case of this proposal), every time it is updated in
Fedora N-1 and/or Fedora N-2, the obsoleted version must be updated. There is no
automation for this and I have been doing it manually when people file bugzillas
or complain on the mailing lists. It is an ungrateful, tedious and never ending job.
- There are retired packages ("components", "source packages") and removed
packages ("built packages", "binary", "subpackages"). The problem is that when
we retire a component, we need to obsolete all packages it (used to) create.
Naturally, this is not always easy to grasp for packagers: Even the change does
not consider the difference at all. Retirement also isn't the only way to remove
a package (subpackages get removed as well).
Generally, I think we should instead strive to have configurable bahavior of dnf
system-upgrade:
option 1) broken deps block upgrades, user go figure (status quo)
option 2) broken deps of packages not part of distupgrade repository behave
like --allowerasing
option 3) all packages not part of distupgrade repository are removed on
distro boundary upgrade
option 4) --allowerasing (already possible)
With alterations for 2/3:
suboption a) this affects all packages
suboption b) this affects only packages installed from "system repos"
(Suboption b) can be achieved trough a .repo file configuration option.)
Then we can have a discussion about the best default for Fedora.
Such solution obviously requires somebody to design it, code it, test it,
support it and maintain it. I cannot speak for the software management team, but
I guess they would have reasons not to do that (such as capacity reasons).
The solution proposed in the change OTOH requires somebody to create the
package, create the automation, keep it up to date, explain to users how to opt
out, explain to packagers what to do, fight broken data, keep it up to date
after the data has been changed by a provenpackager who doesn't understand this
(happens every once in a while with fedora-obsolete-packages), test it
continuously, support different datasets for up to 4 different releases.
As one of the fedora-obsoelte-packages maintainers, I have capacity reasons not
to do this.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
