Steps to reproduce:

$ podman run --rm -it debian:bookworm-slim
# apt update
# apt upgrade
# cat >> /etc/apt/apt.conf <<EOF
APT::Get::AutomaticRemove true;
EOF
# apt install --no-remove base-files

(Or use your favourite chroot or container technology.)

Expected result:

I would expect --no-remove to "win", so that autoremovals are temporarily
turned off for that command, and the command succeeds (in the absence of
any other factors making it fail).

Actual result:

root@d376a962eec1:/# apt install --no-remove base-files
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
base-files is already the newest version (12.4).
base-files set to manually installed.
We are not supposed to delete stuff, can't start AutoRemover
E: Handler silently failed
root@d376a962eec1:/# echo $?
100

This happens whether there are packages due for autoremoval or not (the
failure occurs before apt has decided whether to autoremove anything).
It also doesn't matter whether the package to be installed is already
installed (like base-files) or not (replace base-files with hello).

Workaround: instead use:
apt install -oAPT::Get::AutomaticRemove=false --no-remove ...

Context: in real life, obviously I'm not actually installing base-files:
I'm using `apt install --no-remove` to install a package that *isn't*
already installed, together with its dependencies, while making sure
that if the package isn't installable (due to multiarch skew or other
unsatisfiable dependencies), apt's problem resolution heuristic will
prefer to fail the transaction as a less-bad result than removing the
desktop environment or other important packages.

Thanks,
    smcv

buster. I assume this means APT::Get::AutomaticRemove and/or --no-remove
are sufficiently rarely-used that this interaction hasn't been noticed
before.

    smcv

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

Hmm, I can see that being an issue, but I wasn't actually thinking of
conffile vs. CLI priority here. The reason I say that I would expect
--no-remove to win is that I thought of "don't remove anything, ever"
as being a "stronger" option than "try to remove unused packages".

In my use-case (Valve's steam-launcher package), you're correct to guess
that --no-remove is a command-line option, while
APT::Get::AutomaticRemove=true was coming from (some) users' configuration.

Of course the *correct* way to do this would be to have actual
dependencies, more like src:steam-installer in Debian (which has a
hard dependency on steam-libs and steam-libs-i386 metapackages);
but unfortunately Valve has always documented the way to install
steam-launcher as "download the .deb file and then install it" (with gdebi
or GNOME Software or "apt install ./steam-launcher_*.deb"); so at
the time the .deb is installed, the apt source that would provide its
dependency metapackages is not in place yet, leaving it with no choice
but to try to fix up dependencies via pkexec (or historically sudo)
during first-run after the apt source is in place.

I realise that if Valve was willing to either change their installation
instructions, or bless steam-installer as official, the problem would be
solved; but that's not something that I am able to force, so at the moment
I'm stuck with that constraint.

Given that constraint, we're trying to make steam-launcher do the
least-bad thing, where failing to install dependencies is less bad than
accidentally removing the desktop environment if the dependencies are
uninstallable (perhaps due to multiarch skew or use of other third-party
repositories).

For a use-case with third-party apt repositories, I don't have the
opportunity to put Protected: yes on the user's desktop environment
(and nor would I want to - users sometimes genuinely want to uninstall
GNOME and swap it for Plasma, or similar, and third-party packages
shouldn't prevent that).

At the moment I'm intending to use -oAPT::Get::AutomaticRemove=false on
the command line, because this needs to work with historical versions
of apt, so I'd still need this override even if newer apt versions changed
the priority of these options to match what I had expected.

I need a CLI that is intended to be scriptable, which AIUI means it
should be apt-get rather than apt, and I need to pull in dependencies,
so it would have to be "apt-get --with-new-pkgs upgrade <pkgname...>"
or similar. Are there other reasons to prefer this over
"apt-get install <pkgname...>"?

(Unfortunately steam-launcher is still aiming to at least semi-support
Ubuntu 16.04, which is apt 1.2, so I can't rely on new features either.)

    smcv