#1068637 apt does not always install Recommends

Package:
apt
Source:
apt
Description:
commandline package manager
Submitter:
Vincent Lefevre
Date:
2024-04-09 12:03:02 UTC
Severity:
normal
#1068637#5
Date:
2024-04-08 09:50:04 UTC
From:
To:
The lvm2 package is installed, but not thin-provisioning-tools,
though lvm2 recommends it. This can yield a broken system:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142

the fix of this bug being

   * Make lvm2 recommend thin-provisioning-tools. (closes: #857142)

#1068637#10
Date:
2024-04-08 10:29:17 UTC
From:
To:
Control: severity -1 wishlist
of the system it should be a Depends.

Now back to the topic, this is not a release critical bug in APT. APT
installs any Recommends with easily satisfiable dependencies. Recommends
will get broken easily if there's large scale dependency issues like
now.

This works out well if you Recommend an Architecture: all package and
it Depends on packages that are not available on all architectures -
it is just being skipped on those.

In this particular instance you're getting bit by time_t transition
issues and Recommends disappear on you (even if they may be satisfiable
it may simply be easier to break the Recommends for apt than to figure
out the right solution).

However I do agree with you and I've already set this a couple of times
before that I want to move away from treating Recommends as optional
dependencies that we want to satisfy as many of as we can.

My proposal is quite simple:

 Recommends that point to an existing real package are promoted to
 Depends, except that you may remove them by explicit action (remove
 them after install, mark them for removal before installing, or if
 it is unsatisfied in the installed package it remains unsatisfied).

 This applies to the entire or group. If you Recommends: real | virtual,
 the recommends may also be satisfied by the virtual package.

I do not know what the behavior should be for Recommends exclusively
n virtual packages, I feel like promoting them could have unforeseen
issues, people think less about them than real packages.

Ultimately this may be a bit challenging to implement but I didn't
actually get around to looking at it yet, and it certainly will take
some time to sort out the uninstallabilities this introduces in the
archive especially on niche architectures where Architecture: all
packages are Recommended but not installable.

#1068637#17
Date:
2024-04-08 11:05:40 UTC
From:
To:
It is not mandatory in all cases, but it some cases. In any case,
the "Recommends:" must be honored.

No, lvm2 was installed before the time_t transition. It actually
affects plain bookworm installations (on a machine where I installed
Debian 12.1 on 2023-10-07); you can see with the attached
"dpkg --get-selections" output I had at that time.

#1068637#22
Date:
2024-04-08 17:26:42 UTC
From:
To:
[…]

You haven't mentioned AT ALL if we are talking about upgrade or a fresh
install of lvm2, for the later see below. For the former:

Are you absolutely, positively sure that you haven't ignored apt
(aptitude) telling you that it wont install that recommends while
installing lvm2?

APT (and aptitude?) do not install old unsatisfied recommends on an
upgrade, so the only way of not getting thin-provisioning-tools
installed is either to not have it installed while it was new in which
case apt (and I think aptitude has somewhat similar) output contains:
| Recommended packages:
|  thin-provisioning-tools
Same for Suggests btw which aren't installed by default (but lvm2 has
none). Or you have removed thin-provisioning-tools at some point after
it was once installed.

And yes, as Julian explained, if a package is not installable, that
also leads to a recommends not being installed but same output.

(I somewhat doubt you have managed to install an lvm2 which had not yet
 a recommends on thin-provisioning-tools and upgraded that now to
 a version with that recommends. That would be a new recommends that apt
 tries to install, but might fail for reasons Julian mentioned already.
 Different upgrade-commands-implementations have different approaches to
 that – 'apt upgrade' e.g. tries to detect that and holds the upgrade
 off it does, while 'apt full-upgrade' ignores that. Both work better
 if the archive is a stable state… which tends to be the case with
 stable for obvious reasons. Less so for unstable.)
                                          ^^^^

What time? Before you installed lvm2? That output says lvm2 is
installed. So after it, but what are you trying to tell us then?

That you had lvm2 installed, upgraded it and it still didn't install
thin-provisioning-tools? Well, as explained above, working as intended.


I just bootstrapped a minimal stable chroot with mmdebstrap and behold:
| # apt install --install-recommends lvm2
| Reading package lists... Done
| Building dependency tree... Done
| Reading state information... Done
| The following additional packages will be installed:
|   dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 liblvm2cmd2.03 thin-provisioning-tools
| The following NEW packages will be installed:
|   dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 liblvm2cmd2.03 lvm2 thin-provisioning-tools
| 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
| Need to get 2662 kB of archives.
| After this operation, 9729 kB of additional disk space will be used.
| Do you want to continue? [Y/n] n
| Abort.

In other words your issue with a "plain bookworm" install is
unreproducible (My chroots are configured to not install recommends by
default, so I enable it explicitly on the command line here. There is no
difference in behaviour for apt. I think aptitude reacts differently, but
who knows). If I leave out the flag apt tells me it wont install the
recommends as shown above. What am I doing wrong, where is the bug?


So, if you want to have any chance of us investigating your problem as
a bug rather than as a user-error you will have to tell us what you did
exactly, preferably with easy to follow steps and output. Failing that,
on your bookworm install you might be lucky and still have the
installation/upgrade and such of lvm2 in your history.log(s).
That might shine some light on it as well.


Best regards

David Kalnischkies

#1068637#27
Date:
2024-04-09 00:17:18 UTC
From:
To:
a bit after the installation of bookworm. For the other machine, this
was the status just a bit after the installation of a weekly build on
2024-01-05.

Then, I don't know the internals. But according to Bastian Blank[*]:
"It is installed like everything else." (but see the details below).

[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068560#22

A few hours after the installation of bookworm. You can see that lvm2
is installed, but not thin-provisioning-tools (which is the bug).
I mean that this has always been like that (so, if you think that
thin-provisioning-tools could have been installed as a Recommends,
then removed later, this is not the case).

But what about the usual Debian installation on a real machine?

For the first machine (bookworm), I used an image via
https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/
namely, debian-12.1.0-amd64-netinst.iso, and I did the installation
by using a USB memory stick.
this command; so it came from the Debian installer):

Start-Date: 2023-10-07  13:43:22
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install lvm2
Install: dmeventd:amd64 (2:1.02.185-2, automatic), libaio1:amd64 (0.3.113-4, automatic), liblvm2cmd2.03:amd64 (2.03.16-2, automatic), lvm2:amd64 (2.03.16-2), libdevmapper-event1.02.1:amd64 (2:1.02.185-2, automatic)
End-Date: 2023-10-07  13:43:28

And for the second machine (weekly build):

Start-Date: 2024-01-05  16:54:09
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install lvm2
Install: dmeventd:amd64 (2:1.02.185-2, automatic), libaio1:amd64 (0.3.113-5, automatic), liblvm2cmd2.03:amd64 (2.03.16-2, automatic), lvm2:amd64 (2.03.16-2), libdevmapper-event1.02.1:amd64 (2:1.02.185-2, automatic)
End-Date: 2024-01-05  16:54:14

Now, this is clear that the recommended thin-provisioning-tools
package was not installed together with lvm2.

#1068637#32
Date:
2024-04-09 11:54:05 UTC
From:
To:
Summary of bug(s) so far: lvm2 installed by d-i without its Recommends
Question: Can we solve this once and for all or do we need/want a
 workaround and/or downgrade for lvm2 only to make user happy
[only pun intended]

Merging both into #931283 that seems to be about the same thing.

He likely meant that you have installed it, "like everything else"
because that is what users usually do and you weren't particular clear
that you haven't – and what you used that did for you… lvm2 isn't
"a core package", so there are certainly ways of installing Debian
(even with d-i, which isn't the only way either) without lvm2.

d-i seems to install packages without recommends:
https://salsa.debian.org/installer-team/base-installer/-/blob/master/library.sh?ref_type=heads#L152
That is later dropped for "everything else", but I suppose lvm2 is
installed before that – but I don't know much about d-i or lvm2.


Anyway, it probably isn't a good idea to have d-i install all recommends
while it sets up the machine – better things to do and all that –, but
perhaps it can as one of the last actions (final_apt_preferences ?) run
something like:
| apt-get install --fix-policy
(after the config is removed, or add --install-recommends).

Likely involves demoting some 'Recommends' in the base set to 'Suggests'
through, but they behave like that already if installed by d-i, so that
is probably for the best for consistency alone.

In any case, I will leave d-i folks have fun with this now,
but feel free to ask apt-team if there is something we can help with.


Best regards

David Kalnischkies