Re: Depends/Recommends from libraries
On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote:
> Jonas Smedegaard <email@example.com> writes:
> > Quoting Russ Allbery (2017-03-09 04:24:09)
> >> In general, I don't want to see us place too many restrictions on
> >> Recommends. If you don't want additional helpful programs, disable
> >> installing Recommends by default. I think it's very odd to worry
> >> about bloat while simultaneously installing Recommends by default;
> >> those aren't really consistent things to do.
> > I strongly disagree: We _can_ improve on the default behaviour of our
> > package handling - we need not give up and leave it to power users able
> > to handle arguably broken systems.
> Well, I strongly disagree with you. I think this would take things in the
> wrong direction; I like that software is fully useful when Recommends are
> enabled at the cost of some bloat.
Yeah, but how the _library_ can make a meaningful decision about how
important the dependency is? Only the program that links with the library
knows whether it's a fringe option or something important.
> If you don't want possibly unused software installed, we have a supported
> mechanism for that: disable automatic installation of Recommends.
The policy says:
# This declares a strong, but not absolute, dependency.
# The `Recommends' field should list packages that would be found
# together with this one in all but unusual installations.
Ie, if a substantial part of users don't want that package installed, then,
by the Policy's wording, that dependency is wrong.
What's wrong in the current state is that it looks only from the point of
view of the library: libwrap1 is useless without tcpd, thus it's natural for
it to have an elevanted severity. But that dependency is wrong from a more
global point of view. That's why I'm proposing making the decision a
responsibility of programs which link to the library.
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!