I have sympathy for such proposal, but the implementation does not respect all the possible corner cases. 1) It does not reflect, that this is not just about retired packages, but also (or mainly?) about subpackages, which we don't retire. 2) The point (1) is closely related to -debuginfo packages topic [1] which I re-raised recently with not as much attention as I would like. Also, I wonder what is wrong with "dnf autoremove", which is supposed to remove unused leaf packages, which were not explicitly installed? Vít [1] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/RBC7I5IQDD7R7CREKYTWLIVY6PZIWOTQ/ Dne 15. 06. 20 v 21:47 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages > > == Summary == > All retired packages are obsoleted by `fedora-retired-packages`. > > == Owner == > * Name: [[User:msuchy| Miroslav Suchý]] > * Email: msuchy@xxxxxxxxxx > > == Detailed Description == > Right now `fedora-obsoletes-package` retires packages which cause an > issue during an upgrade. We do nothing about all other retired > packages. Now imagine the following story (it already happened many > times): > > 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 retires the > package (or orphan and it later become retired). > > Because the package is a 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. > > == Feedback == > > After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5 > discussion with fedora-obsolete-package maintainer] I filed this > Change proposal to include a wider audience. > > See relevant [https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/UTHLSBCLDTFOVEDVQR4XOMNKBJXSHOTF/#Z5D77LVDWWTO7HSP43MYQ7F5MKL6D6TK > thread on devel mailing list]. > > == Benefit to Fedora == > * 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. > > == Scope == > * Proposal owners: > > Create package `fedora-retired-packages` as sub-package of > `fedora-obsolete-packages` > [https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532] > Edit https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages > guidelines with: > > The retired package should be obsoleted by one of: > > * fedora-obsoleted-packages - if the package can cause problem during > upgrade to next version of Fedora > * fedora-retired-packages - in all other cases > > It is enough to open an issue on > https://src.fedoraproject.org/rpms/fedora-obsolete-packages > > * Other developers: > No other work should be necessary. > > * Release engineering: > This is optional. I may work with rel-eng to change > https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_packages.rst > to automatically create PR for `fedora-obsolete-packages` > > * Policies and guidelines: As stated above > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages > will need an update. > > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > During an upgrade, all retired packages will be automatically removed. > > User may opt-out by: > <pre> > $ cat /etc/dnf/dnf.conf > [main] > ... > exclude=fedora-retired-packages > </pre> > > > == How To Test == > 1. Upgrade to next version of Fedora. > 2. Check all retired packages are removed. > > == User Experience == > - Packages that are no longer maintained are removed during a > distribution upgrade. > > == Dependencies == > This update has no dependencies on any other package. > > == Contingency Plan == > * Contingency mechanism: Drop `fedora-retired-package`. Or remove > `Obsoletes` from this sub-package. > * Contingency deadline: Beta freeze > * Blocks release? No > > == Documentation == > TBD > > == Release Notes == > TBD > > _______________________________________________ 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
