Oleg Gusakov a écrit :
> The tree could be walked in two directions, and these approaches are
> equivalent, except for b and c optionality:
> 
> Representation #1: P2
> 
> a1 -> b1 or b2 or b3
> a1 -> c1 or c2
> 
> b1 + b2 + b3 <= 1  # this one implicates that b is optional
> c1 + c2 <= 1       # this one implicates that c is optional
> 
> 
> Representation #2: Mercury
> 
> b1 -> a1
> b2 -> a1
> b3 -> a1
> c1 -> a1
> c2 -> a1
> b1 + b2 + b3 = 1
> c1 + c2 + c3 = 1
> 
> In the second one it's easier for me to keep the tabs on the generated
> system. Timewise both are solved in 10s of millis.

Oleg,

I agree that you can encode either "provides" or "depends" semantic
using constraints.

However, you cannot ask the same question:

Representation "depends":

Append the package you want to install (a1=1).
Ask for a solution consistent with the constraints (or the best one).

(What do I need to install to be able to install a1).

Representation "provides":

Append the packages you have.
Ask for all the packages that can be safely installed according to the
constraints.

(what can I install if I have all those packages available in my
repositories)

If you append a1=1 in your representation, the Xx -> a1 constraints are
all satisfied, so are useless to discriminate a possible solution.

You find the right solution because of the equalities that force one bi
and one cj to be satisfied.

Just compare the two approaches on the same example with

additional d1, d2, d3 and e1, e2, e3, e4 in your repository.

I suspect that you will anyway throw them away because they will not be
part of the dirty tree.

So I have a simpler representation for you:

Representation #3: Mercury new proposal

b1 + b2 + b3 = 1
c1 + c2 = 1

Together with the objective function, it will find the expected answer :)

        Daniel
-- 
             Daniel Le Berre mailto:lebe...@cril.univ-artois.fr
             MCF,    CRIL-CNRS UMR 8188,    Universite d'Artois
             http://www.cril.univ-artois.fr/~leberre

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to