[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1068637: apt does not always install Recommends



Control: severity -1 wishlist

On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote:
> Package: apt
> Version: 2.7.14
> Severity: serious
> 
> 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)

That's a packaging bug. If the tool is mandatory for correct behavior
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.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en


Reply to: