Re: obscure <constraints> question

Will wrote:

> Let us say that, in searching for a field thing (along a
> prototype path), you encounter
> 
>   <constraint><dependency name="foo" version-spec="eq 1.2.3" /></constraint>
> 
> and then subsequently
> 
>   <constraint><dependency name="foo" /></constraint>

I'm not understanding the need to solve a problem with
<constraint> here... rather it is <dependency> which smells
bad...

(excuse my from-first-principles thinking, I'm new to the
game but interested in this thread, perhaps my naivety
will help clear your thinking...then again Jonathan's reply
probably says the same thing, more concisely)

In  your case these two <constraints> were encountered in
two separate implementations of <field> somewhere along the
(depth-first, left-to-right) prototype path, yes?

Usual use of <constraint> is effectively an if-elsif construct
in reverse, right? As the web page says:

 <install-bits>
  <constraint><host-spec name="hppa-hpux"/></constraint>
  <param name="MAKE">/usr/bin/make</param>
 </install-bits>
 
 <install-bits>
  <constraint><host-spec name="solaris"/></constraint>
  <param name="MAKE">/usr/ccs/bin/make</param>
 </install-bits>

... would resolve to one or the other flavour (or neither)
while building up a <install-bits> from the path.
I've got that. It's an assertion which prunes the tree.

> .  At the moment, the ARK engine seeks to satisfy these two
> constraints entirely independently.

Of course. In order-encountered as well (depth first and
left-to-right) which seems intuitive for the prototype
mechanism. You would specify 'overriding/detail' last,
after 'common/defaults'.
(hint: that may be the problem here... ;-)

> So, assuming we're talking packages, imagine we actually
> have foo packages versions 1.2.3, 2.3.4, and 3.4.5 all
> installed.
> 
> The first constraint would be satisfied by package foo
> version 1.2.3; the second constraint would (and might) be
> satisfied by any of the three (because there is no
> 'version-spec' attribute on the second constraint).

Yep, got that and don't see the problem with it yet in the
definition of how a <constraint> should behave. Our goal
was to build up a value for <field> and different xml files,
protos and finals, got to contribute fragments of that value,
if constraints were satisfied for each contribution. Some of
those constraints were more general than others. That's OK
because the fragment of 'value' would always be more or less
generic/specific in line with the constraint.
i.e. we'd be pruning just the leaves, or whole branches.

> 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.

Now you'rre off the street into a <dependency> alley :-)
<dependency> here ceases to smell good in the <constraint> stew.
You shouldn't need to do anything special to <constraint> in
order to guarantee the (desirable) behaviour above.

While traversing the tree, <constraint>s beget <dependency>s and
these are recursed into i.e. the 'make it so' property you talk
about in the documentation.. They presumably evaluate to success
or failure, and if type="essential" the game ends right there.

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.

That's the problem. <dependency> must not be treated to
depth-first, left-to-right evaluation order.

[In fact a more useful order for <dependency> would be the exact
opposite; its more likely that the team xml would have the
overriding detail of a dependency which implies install-this-
specific-version before looking at the prototype, whose
more-generic constraint would then of course be satisfied. If
version is in the prototype its probably not often overridden.]

No matter. Policy shouldn't be to _guess_ the best _order_, rather,
to evaluate <dependency> generic- or specific-ness properly. i.e:
- break <dependency>s out of the <constraint> evaluation order
- stack them up while evaluating the whole <field> prototype
- remove ones which are satisfied by more-specific ones (eg remove
  'foo' because 'foo--1.2.3' is there) but make a note of these as you
  will need to provide references to the specific one when the field
  which asked for the generic one wants some info about it eg install
  dir
- Then chug through them in any order at all (they will have their
  own inter-dependencies, perhaps, which may refine the actual
  'order' later).
- Finally, second-pass the <field> tree refining based on what we
  now know about the <constraint> values for these <dependencies>
  (and yes, <dependency name="foo" /> would return references to
  the more specific dependency which eclipsed it, in order for us
  to interrogate the dependency package's fields in detail.)

Caveats: I dont know the code, so this may of course mean that you
need to have (add?) a second pass through the tree, i.e.
(1) parse/walk proto tree, pruning <constraint>s and gathering
    <dependency>s
(1.8) optimise dependencies removing generics which match specifics
(1.9) evaluate dependencies in any order
(2) walk proto tree again, pruning by <dependency> results, execute
    code fields as you go
I dont think this will be hard :-)

More radical proposals:
(1) <dependency> is not a <constraint> Break them out in the xml
    while doing the above....allows for an easier parallel-
    transition as well.  (horrible thought, is <dependency> a
    Sidai thingy not an ARK thingy?)
(2) remove 'type="essential"'. Dependencies are always essential.
    don't allow 'ark package install' to be true until they are
    satisfied. But..... don't fatal at the first encountered one.
    Evaluate them all and report them all if unsatisfied (your
    2-pass traverse will allow this to be easy, and you just
    wouldnt start pass 2 unless evaluate dependencies was true)

> Why: it will make it easier for a site-team to specify
> versions in its own xml files, and for "policy" teams
> (e.g. Sidai) to express constraints, knowing that they tie
> up with what the individual site wants.
>
> Opinions?

like my coffee, sorry.... :-)


Cheers,
_________________________________________________________________
Gordon Allan, Verilab, mailto:[email protected], +44-1698-464504