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

Re: no{thing} build profiles



On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
> Adam Borowski <kilobyte@angband.pl> writes:
> 
> > Thus, I'd re-propose a Policy change that was mentioned in multiple
> > threads in the past:
> 
> > "A runtime library should not Depend: or Recommend: on any packages than
> > other libraries or dormant data, unless the library or its programming
> > language provides a convenient scheme for it being loaded only
> > optionally.  Any such dependencies should be declared by programs linked
> > against such a library."
> 
> I think the prerequisite for making a change like this would be for the
> library to be able to surface this transitive requirement in metadata so
> that debhelper could support automatically adding it to the dependencies
> of all linked programs (and I'm not sure that sort of collapse of our
> dependency structure is a good idea).

That would be a bad idea -- we don't want gratuitous dependencies all
around.  Just because I use xfce doesn't mean I want a daemon for some old
kinds of iApple iJunk, yet Recommends: chains install that.

It's the program that depends on the library that can make an informed
decision: sometimes, the program needs that daemon to function, other times
it can interface with it in a corner case that's wanted by 0.01% of users.
The library's maintainer has an elevated view of its importance, but a lot
of the time it's only an optional part.

> Otherwise, if a user does want to use the functionality that GnuPG
> provides but doesn't have gnupg installed since it's been relegated to a
> Suggests, do they have much hope of figuring out what's wrong and how to
> fix it?  Or will the package just look broken?

In this case, the program that links against libgpgme gets to decide how
important that dependency is.

> Minimal installation size is *not* the only goal here.  Ease of use and
> lack of surprise is important to.  Personally, I'd much rather have
> numerous unused packages installed than to have something break in an
> opaque way when I try to use it, even if I'm unlikely to need to use it.
> This is particularly the case when the additional packages don't do things
> like run services or (much) increase the attack surface.

I'd agree with you if this problem happened only in moderation.  But it does
not, to the point of recommends being mostly unusable.  Even worse, if you
tell apt to install package A that Recommends B (directly or indirectly) and
B is not installable (like, by some hold/conflict/apt preferences/etc), apt
refuses to install A at all, not even telling you what the problem is.

What I want is to get Recommends back to a state where they would be useful
and policy compliant -- ie, "list packages that would be found together with
this one in all but unusual installations".


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄⠀⠀⠀⠀ and 1 who narrowly avoided an off-by-one error.


Reply to: