On Wed, 03 May 2023 at 23:52:54 +0200, David Kalnischkies wrote:
> 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.
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".
> 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.
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).
> 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…
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).
> 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).
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
