Removing unmaintained packages from your Fedora machine should require explicitly opting in

June 19, 2020

Ben Cotton recently wrote an entry on Fedora potentially removing unmaintained packages from your system under some circumstances, because there is a Fedora change proposing to remove 'retired' packages. The change proposal contains the following remarks:

Upgrade/compatibility impact

During an upgrade, all retired packages will be automatically removed.


How To Test

1. Upgrade to next version of Fedora. 2. Check all retired packages are removed.

In the ending of Ben Cotton's article, he says in passing "[B]ut we have to make sure we’re clearly communicating what is happening to the user" if package removal happens. I will go further than that.

Removing packages from your system on Fedora upgrades should require an explicit opt-in, and this opt-in should be able to show you the list of packages being removed.

Going beyond that, Fedora should never remove unmaintained packages from your system without this opt in, for example they should never push out an updated fedora-retired-packages RPM in Fedora updates.

Removing unmaintained packages from people's systems is removing functionality with no replacement or equivalent. This can break what people are doing with their Fedora machines, and doing so is both morally wrong and dangerous in practice. It doesn't take too many cases of Fedora upgrades or Fedora package updates breaking things without warning for people to stop doing either of them.

Because this requires explicit user opt-in and a UI and so on, and additional unmaintained packages should not be removed during the lifetime of a Fedora release, I think that removing retired packages during upgrades should live in the upgrader, not be implemented as an RPM package (or at least not as an RPM package that's installed by default). The upgrade system is the only place that is in a position to actively prompt the user in a meaningful way to obtain explicit, informed opt-in consent to this.

(The lightweight version of this would be to require people to opt in in advance by installing the special fedora-retired-packages RPM. People who know enough to manually select and install the package can be presumed to know what they're doing and be making an informed choice to accept whatever package retirements Fedora wants to push.)

PS: I was going to consider this different from the existing situation with fedora-obsolete-packages for various hand-waving reasons, but the more I look at what packages Fedora has removed through the fedora-obsolete-packages RPM, the more I think that the two should be mostly merged together and treated very similarly (ie, require explicit opt-in). The current fedora-obsolete-packages goes well beyond merely removing packages that cause upgrade problems (unless you take a rather expansive view of 'upgrade problems').

Comments on this page:

I think making a moral argument might be a little strong. I would make the stronger argument that leaving unmaintained packages on people's systems without them knowing it, leading to the build up of CVEs and potential expiration by bad actors would probably have a stronger moral, really more ethical, component.

That said, I can understand the frustration, though I suspect we are both talking about it edgee cases :-) Edge cases are a constant struggle. They have to be stack ranked with a finite set of resources.

By cks at 2020-06-20 15:04:32:

I think that the obligations of distribution maintainers start with 'first, do no harm'. If there is a known issue that renders some piece of software actively dangerous, removing it is probably doing less harm than leaving it around. But if there is no known issue, removing it just in case is potentially an active harm.

(There's a potential practical difference between things installed due to being dependencies and things explicitly installed by the person using Fedora. I feel that the latter should need a quite strong case to remove. Removing things that are only dependencies isn't totally safe, people may be relying on them even though they weren't installed directly because they're there, but an explicit installation of a package is a very strong sign that the person actively wants it and removing it will be doing harm.)

Written on 19 June 2020.
« People's efficiency expectations for generics in 'Go 2' and patterns of use
The additional complications in DNS updates that secondary DNS servers add »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jun 19 22:44:24 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.