Re: obscure <constraints> question

GordonA writes:

> My assertion: The second <dependency> ( note that I've stopped
> talking about <constraint>s )
>       <dependency name="foo" />
> must *always* evaluate to true, if 
>       <dependency name="foo" version-spec="eq 1.2.3" />
> evaluates to true. No matter in which order they were encountered
> in the prototype path.

(Gordon, lots more good stuff in your mail than I can handle
at this time of day :-), but here's an item or two...)

First, bear in mind that a "dependency" constraint is just
saying "you must have run the such-and-such method for
such-and-such a thing" (of any type).  No more, no less.

What you say above is exactly true.  The more general
dependency *is* certain to be satisfied; the question is
whether we should force it to be satisfied in the same way
as the One We Saw Earlier (TM).

This matters, because we have ways to query the constraints
that have been satisfied in grokking this field, e.g.

  <param name="apachedir">!field.dependencyDeployDir('apache')</param>

  <param name="configure_args">--with-apxs=@param:apachedir@/bin/apxs</param>

So in practice it can matter what version we record in the
satisfied constraints.

None of this really addresses your more salient points; I'll
probably talk to you about those.  Thanks,

Will