Re: obscure <constraints> question

Jonathan Hogg writes:

> > Proposal: in satisfying a constraint, we give preference to
> > constraint-satisfiers *already encountered* for this field.
> > In the example above, the second constraint would be
> > *guaranteed* to be satisfied by package foo version 1.2.3,
> > because we've already used that to satisfy a constraint.
> 
> I guess that makes sense in the terms of the normal order of constraints,
> but wouldn't the more correct thing be to use the most specific constraint -
> with 'foo 1.2.3' more specific than 'foo'.

OK, I'll need to think about that.

> Surely if we encounter 'foo 1.2.3' and 'foo 1.2.4' we want this to be an
> error, ...

Why is this an error?  Imagine you had a package for 'foo-wrapper'
which let you choose between 5 versions; you might well have
(say) a 'configure' field that included something like:

<constraint><dependency name="foo" version-spec="eq 1.2.1" /></constraint>
<constraint><dependency name="foo" version-spec="eq 1.2.2" /></constraint>
<constraint><dependency name="foo" version-spec="eq 1.2.3" /></constraint>
<constraint><dependency name="foo" version-spec="eq 1.2.4" /></constraint>
<constraint><dependency name="foo" version-spec="eq 1.2.5" /></constraint>

(All you're saying is: the 'reveal' [default] methods for
packages foo--1.2.{1,2,3,4,5} must have been run.)

Will