Talk:Changes/RetiredPackages

A separate package, or a dnf plugin?

I think improving the discoverability and management of retired packages is a great idea, personally. There is some major cruft that's accumulated on my systems over the years, as I'm well aware. It can be tricky to manage.

That's why I'm just wondering whether it makes sense for this to be a wholly external package, separate from dnf, vs. a plugin that enhances dnf with new abilities to manage retired packages.

I'm thinking of something like a python3-dnf-plugin-retired that adds new commands to dnf that allow examination and management of "retirees". So that something like the following might be possible:

# Instead of
$ sudo remove-retired-packages 32

# Perhaps one of these:
$ sudo dnf list-retired 32
$ sudo dnf retired-since 32

# And to start the interactive cleanup process...
$ sudo dnf remove-retired 32

Yes, in a sense sudo dnf list extras is already that, and users can already manage the packages themselves if they want to. Providing a more "guided" workflow for less technical users is a great goal, but that doesn't mean it's necessarily incompatible with dnf integration. And I worry that the more disconnected tools there are that can manage the system's package collection, the more they step on each other's toes.

(Like, will the remove-retired-packages tool respect DNF package locks? Already Gnome Software doesn't, as I discovered the one time I made the mistake of letting it do an update and found my locked packages suddenly replaced with new versions.) -- Ferdnyc (talk) 04:30, 8 October 2021 (UTC)

(In fact, one great way to deal with retired packages is to just unmark them as user-installed (sudo dnf mark remove package), after which sudo dnf autoremove will sort most of them out for you.) -- Ferdnyc (talk) 04:41, 8 October 2021 (UTC)

I would love to have this feature in the DNF at the end. But changing DNF is hard. And there is a good reason for that as everyone wants to have DNF mature and stable. And with the current migration of the code to libdnf getting the new feature is as twice as hard. I want to stabilize the code first outside of DNF - and come with the ideas like the "unmark" and see how it works and what are the bumpers in the wild word and only then try to push it to the DNF itself. Msuchy (talk) 09:17, 11 October 2021 (UTC)