On 2018-10-26 at 00:51, Russ Allbery wrote: > The Wanderer <wanderer@fastmail.fm> 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