Description of problem: I have just upgraded to F32 and on my system, there is a lot of packages (128 to be precise) that have been orphaned/retired in Fedora. Some of them are fc30, fc29, but I have even one with fc23. They do not qualify for fedora-obsolete-package because they do not cause an issue during dist-upgrade. But when e.g., libmm-qt.fc23 will start causing issues during upgrades - let say during upgrade f34->35 - I assume everyone will hesitate to add this package to fedora-obsolete-package as it is really old (it already happen in one of my previous reports). What I want to propose is to create new subpackage fedora-retired-packages and every time when package is retired from fedora (and it is not obsoleted by something) it will be automatically added to this fedora-retired-packages. This way you can opt-out and have only fedora-obsolete-packages. Or have both packages installed and clean system. Comments are welcome.
> added to this fedora-retired-packages Added how? Obsoleted? > This way you can opt-out and have only fedora-obsolete-packages Opt out how? How does this essentially differ from defaulting to --allow-erasing for the Fedora repos on distro-upgrades? Except for a lot of metadata and more work to automate this?
> Added how? Obsoleted? Yes. >> This way you can opt-out and have only fedora-obsolete-packages > >Opt out how? Uninstall fedora-retired-packages in case you want to keep that old package.
> Uninstall fedora-retired-packages in case you want to keep that old package. If the package exists in the repo and obsoletes packages, it will simply obsolete them, there is no "install or uninstall" for opting in or out. I don't understand what are you proposing, sorry.
OK. More detailed. We have package "foo". It is a leaf package. No one requires it. It uses just basic libraries. A user installs it during F32 lifetime. Around F35 the upstream dies. Around F37 Fedora maintainer retire the package (or orphan and it later become retired). Because the package is leaf package, it causes no pain during upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And then during upgrade to F43 it suddenly causes a problem. But because it is .fc37 everyone will hesitate to add it fedora-obsolete-packages.fc43. Additionally, during F38-F43, users may expect that their system is fully updated and they have no security issues. But it is not true about package "foo", which no one maintains. And users are not aware of that because he does not follow fedora-devel mailing list. Obviously. What I propose is: As part of the retirement process we add the to fedora-retired-packages: Obsoletes: foo < %{latestversion+1} And during upgrade from F37->F38 the package will be removed. If the user wants to preserve the package (e.g., because it moved to Copr), he simply uninstalls and protects the installation of fedora-retired-packages. But that will be an informed decision. The benefits are: * we do not leave unmaintained packages on a user's machine. * We make sure that archaic packages do not break upgrade between two versions of Fedora.
That basically means we remove all retired packages on distro boundary upgrade unless the user explicitly prevents that by taking a very specific non-obvious action. Why don't we change dnf system-upgrade to do that instead? I've proposed that on the mailing list in the past and I was told this is not the best solution. I cannot find the thread now. Either way, I don't think this bugzilla is a best place for the discussion. Other people who have something to say on the topic are not here.
(In reply to Miro Hrončok from comment #5) > Why don't we change dnf system-upgrade to do that instead? I've proposed > that on the mailing list in the past and I was told this is not the best > solution. I cannot find the thread now. Found it! https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z5D77LVDWWTO7HSP43MYQ7F5MKL6D6TK/
Based on your withdrawal of https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages I am closing this. Thanks for investing the energy to making the proposal and listening to the feedback.