On Wed, Feb 14, 2018 at 10:01:40AM +0100, Julian Andres Klode wrote: > # Automatic autoremoval I have to say, I dislike packages being removed in a dist-upgrade (or in any command really) as it forces me to look up NOW if that is okay because its some sort of empty transitional package now, if its a transitional package, but my special snowflake system still needs it to function (e.g. all dependencies have learned to type "bar" instead of "foo", but my fingers haven't yet) or if this is due to a conflict and I need to get used to a new way of doing something. Currently I can be sure that a remove is due to a conflict… (sadly, some of those conflicts are artificial for spring-cleaning proposes and would belong in one of the first two categories & break in upgrade edge cases). After all, applying upgrades seems more important than spring cleaning and people get really confused if the app they use every day is removed by apt – until they have enough time to figure out that its now just called app2… but some of these users will never figure it out and hence never upgrade out of fear. Functionality to "rotate" away stuff like kernels (even more) automatically is a good idea and there might be other things (my system seems to accumulate gcc versions, database systems, too, …), but intermixing this with transitional packages (= "oldlibs") I am not so sure. And that isn't the "interesting" cruft: The stuff removed from the archive with no direct upgrade path is far more dangerous in the security and "cruft which might break future upgrades" department – and for that stuff it is not really a good consideration if the package was once manually installed to begin with… I think for apt a "janitor" command looking at these things and suggesting removes seems more beneficial. If the higher levels want to perform some of these janitor tasks by default all power to them. Perhaps even in apt we can do some of these janitor tasks in some commands by default as well. I just think it seems better to introduce new commands/options rather than to overload existing ones. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature