Re: Opt out style recommends
Tollef Fog Heen <tfheen@err.no> writes:
> ]] Russ Allbery
>> I think a more correct fix would (unfortunately) involve a new binary
>> package field that we don't currently have: Depends-Shallow (for lack
>> of a better term) that acts like Depends *except* disables Recommends
>> processing for anything below the shallow dependencies in the tree. So
>> if everything you're installing only Depends-Shallow on
>> libimobiledevice4, you don't get the recommendation; if anything
>> straight depends on it, you do.
> I think I want something like Recommends that get less and less weight
> the further they get from something you explicitly requested. Direct
> recommends: 1 point, One step indirect, 0.8 point, two steps 0.8^2
> points, etc. One point or more -> install. You can then also do things
> like adding together scores, so if A, B and C all suggests D, you might
> get that, even if none of them would pull it in by themselves.
> (Weights are obviously pulled out of thin air, experimentation would be
> needed to find sensible values.)
Distance is being used as a proxy for "likely to interfere with the
usability of the program." It's not a bad proxy, but it would be ideal if
we could directly annotate this, since often the maintainers involved know
exactly what weight should be placed. There are some long dependency
chains that actually need a strong dependency the whole way.
And largely maintainers can do that annotation, using Depends, Recommends,
and Suggests. The major place where this breaks down is with shared
libraries, since, due to how dynamic linking works, even shared libraries
only used in specific configurations have to be listed in Depends. But,
because the shared library may be unused other than by mapping it during
process startup, all of its dependencies (of any strength) that don't
interfere with startup mapping should be deprioritized.
In other words, the root of the problem is that we're forced to take
artificially strong dependencies that aren't warranted by the
functionality of the library due to the implementation of dynamic linking
and the fact we want startup binding instead of lazy binding on first call
(for some justifiably good reasons).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: