On Mon, Apr 24, 2023 at 04:11:37PM +0100, Simon McVittie wrote: > On Mon, 24 Apr 2023 at 15:41:07 +0100, Simon McVittie wrote: > > $ podman run --rm -it debian:bookworm-slim > > This is not a new problem: it's also reproducible in at least bullseye and > buster. I assume this means APT::Get::AutomaticRemove and/or --no-remove > are sufficiently rarely-used that this interaction hasn't been noticed > before. They are. Every non-default option is… The problem with those two is that they are contradicting each other and giving a preference to one or the other is hard as the code has no idea if any, all or none of them were given on the command line, via a config file (and which one at that) or via the command line but as a conf option / in a conf file… it all the same from a code pov. It is not the first time I did evil things, even to --autoremove [0], but this time around it might be best to have apt ignore an option like --autoremove (perhaps with a warning) if it encounters --no-remove set. It is kinda unlikely that users really have --no-remove in a config file as it a rather unpractical option, so that might make sense/be fine. That said, if you are scared of "important" packages being removed, you could just mark them as "Protected: yes" and have apt (and dpkg) ask for more force… Also, you might be able to slightly abuse 'apt upgrade <pkgname>' after all this command does not upgrade <pkgname>, but upgrades the system after tagging <pkgname> for installation (that is the most simple form of what the commit I pointed to means with "allowing pkg modifiers for the upgrade commands" btw). Best regards David Kalnischkies [0] https://salsa.debian.org/apt-team/apt/-/commit/c89b22c285d6c4a3cb64689ff26e84af4d1477f2
Attachment:
signature.asc
Description: PGP signature