On 2024-04-21 12:03:05 +0200, David Kalnischkies wrote:
> On Sun, Apr 21, 2024 at 03:35:28AM +0200, Vincent Lefevre wrote:
> > > root@qaa:~# dpkg -s libtest-fatal-perl:amd64
> > > dpkg-query: package 'libtest-fatal-perl' is not installed and no
> > > information is available
> > > Use dpkg --info (= dpkg-deb --info) to examine archive files.
[...]
> > Well, this isn't really the right explanation. This is due to an
> > output bug in apt, which should have output "libtest-fatal-perl:all"
> > instead of "libtest-fatal-perl:amd64".
>
> That might be your preference (now), but it would be wrong in terms of
> apt and I am sure if you think a bit more about it you will agree:
>
> A package is not arch:all. People say that all the time, but only
> because they mean that "this version of the package is arch:all" as we
> tend to talk about a *.deb file as a package and that contains
> a specific version.
>
> If apt were to display "libtest-fatal-perl:all" it would mean that if
> that package becomes arch:any in the next version apt would need
> to show "removing: libtest-fatal-perl:all" and "new install:
> libtest-fatal-perl:amd64" instead of as an "upgrade" among many other
> very annoying things around architectures.
>
> So, for apt, "libtest-fatal-perl:all" is treated like
> "libtest-fatal-perl:native" aka "libtest-fatal-perl:amd64" for you, so
> that if a binary package is arch:any or arch:all is an implementation
> detail for a user – as it should be – as that changes over time.
> The native architecture does not change as often, if at all.
>
> So, in other words, for apt a "package" is usually a set of versions
> which can have different architectures, while for dpkg a package is
> a single version (except if it is not, like in that same arch:all to
> arch:any flip; but users don't speak to dpkg that often and especially
> not in that moment. apt does for them…).
>
> In a way, you could complain that dpkg is so anal about the arch
> instead, but in its own world and context, it makes sense.
But here, "apt install ..." outputs libtest-fatal-perl:amd64, which is
a particular version of this package. And just after the installation,
"dpkg -s ..." refers to exactly the same version. So one should expect
that both tools use a common name to designate the package.
> > So, there's only a "Suggests", and note that I do not install
> > "Suggests" by default.
>
> While you don't install Suggests via `APT::Install-Suggests` which is
> `false` by default, that has no bearing on the autoremoval.
>
> Controlling autoremoval behaviour is `APT::AutoRemove::SuggestsImportant`
> which defaults to `true` as the autoremover could potentially break some
> usecase for you that the suggests enabled and you have grown attached to
> even through the suggests was once installed for another reason.
OK, I had actually that on my old machines, but for some reason,
I didn't remember that and didn't notice that this was missing on
new machines (and there was a bug in my script that checked the
consistency of the config between machines).
But the fact that this is a hidden setting did not help, i.e. it is
not mentioned in the documentation (apt(8), apt-get(8), apt.conf(5),
apt-config(8) man pages, APT User's Guide), while the description of
"apt autoremove" is misleading ("dependencies" is used twice in the
same sentence with 2 different meanings!).
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
