Web lists-archives.com

Re: no{thing} build profiles




On 2018-10-26 at 00:51, Russ Allbery wrote:

> The Wanderer <wanderer@xxxxxxxxxxx> writes:
> 
>> On 2018-10-25 at 20:00, Russ Allbery wrote:
> 
>>> The Depends field should be used if the depended-on package is 
>>> required for the depending package to provide a significant
>>> amount of functionality.
> 
>> This does not actually seem to conflict with the "would be found 
>> together in all but unusual installations" definition for
>> Recommends; in a case where the depending package can still provide
>> meaningful functionality without the depended-on package, but will
>> miss "a significant amount of functionality" if the latter package
>> is not present, both definitions would seem equally applicable.
> 
> I don't know why you would expect otherwise?  That seems entirely
> natural and expected given that Depends is a stronger relationship
> than Recommends, and therefore is naturally a subset of the things
> that would qualify as Recommends.

I think I was expecting that, since both definitions say "should", and
"should" is a statement of what the right thing to do is, and you cannot
do both things, the definitions would necessarily point to only one
option as the one which you "should" do.

(The distinction vs. "must" is that "must" is a statement of what the
*required* thing to do is; with "should" the maintainer's decision can
override, with "must" it cannot. In both cases, the only-one principle
would apply.)

Since "you should do both" is not an option, it seems inappropriate to
my mind's eye for the Venn diagram of the recommendations to have any
overlap; any place where one would otherwise overlap the other needs to
be accounted for, and carved out of one of the two. Otherwise, no
recommendation is actually being provided.

> You choose the strongest relationship that is applicable.

I'm not sure that's clear from the given definitions, nor that it should
necessarily hold. Is there any statement which would make that explicit?
I haven't noticed one in a quick look through Policy 7.2, but it's
entirely possible that I've just missed it.

Consider a case like "Package A's significant functions are X, Y, and
Z. In order to do Z, package A needs package B. However, there are
unusual cases where someone might reasonably not care about being able
to do Z, but still want to do X and Y.".

In that situation, both definitions apply, and the definition you cited
states that Depends should be used, but the definition of Recommends
states that Recommends should be used. Although Depends is the stronger
relationship, it's not clear that Recommends is not the better choice.

Two mutually-exclusive "should"s cannot be simultaneously true.

Yes, in practice the maintainer's-discretion aspect of "should" would
almost certainly govern (no matter which of the two is chosen), but IMO
the existence of that escape hatch does not justify the existence of the
two contradictory "should"s.


I suppose, on consideration, that this boils down to me being a grumpy
pedant about language - which isn't necessarily helpful in a discussion
that's more related to technical merits... so on that basis, unless
someone chimes in to agree with me that this is worth pursuing, I expect
to drop the subject. (At least for purposes of this thread.)

That's especially true since, now that I'm awake enough to think of it,
the simplest (albeit not the most elegant) way to address the problem I
see would be to revise the Recommends definition to something like
"packages for which Depends does not apply, but which would be found
together with this one in all but unusual installations" - and that's a
moderately clunky construction, which smacks enough of pro-forma
boilerplate to seem inappropriate for this sort of context.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature