Bug#1034790: apt: APT::Get::AutomaticRemove true + --no-remove results in failure to install: Handler silently failed

[Simon McVittie <smcv@collabora.com>]

Package: apt
Version: 2.6.0
Severity: normal

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