Daniel Le Berre wrote:
Gilles Scokart a �crit :
An Ivy like function might be nice as well.;-) But there is a piece
that I miss. How did you handle conlicts? I means not multiple
possible solution, but real conflicts. This seems to be incompatible
with a strtict system of constraints.
If I take the example :
A depends on B:1 and C:1
B:1 depends on C:2.
I think maven will take C:1 (first levle in the dependency tree), Ivy
would by default take C:2 (because it resolve conflicts by taking the
'latest' version). What will mercury do? My understanding is that
the SAT resolution will say there is no solution. What practical
solution do you propose for Mercury users? Do you ask them to fill a
DependencyManagment section for the the module that are in conflicts ?
>From a pure logical point of view, there is no solution to that system
if you add the constraints that you would like to install A and that C:1
and C:2 cannot be installed together.
Daniel is absolutely right, if the dirty tree looks like that, there is
no solution, Because it represents the dependencies:
a:1 dep.on b:[1,1]
a:1 dep.on c:[1,1]
b:1 dep.on c:[2,2]
No solution, because both b1 and c1 are required for a1, c2 required for
b1 and c1 contradicts c2. This picture would change if some dependencies
are declared "optional", or there are "include/exclude" clauses in any
dependency
But this illustrates an interesting rule we are dealing with:
b:1 as a dependency, could in interpreted in 3 different ways:
1). b:1 = b:[1,1]
2). b:1 = { b:x | x >= 1 } - OSGi standard definition
3). b:1 = { b:x | x exists in the dirty tree } - a.k.a soft range, so
it could be 0.9.7 or 1.3, depending on the tree and "optimization
policy" - see below
Mercury can do all 3, default is #3, #2 could be enabled with an option.
#1 could easily be added, but is too restrictive and will break a lot of
builds right away, so it's an exercise in completeness, not real life.
Now, since there is an optimization function, it is possible to encode
conflicts in the constraints:
A depends on (B:1 or ConflictB) and (C:1 or ConflictC)
B:1 depends on (C:2 or ConflictC)
And minimize the sum of conflicts in the optimization function.
With the optimization function provided earlier by Oleg, the selection
between C:1 and C:2 would be C:2, because it prefers latest versions,
like Ivy.
As Mercury is a library, the preference ("optimization policy") is
passed in as a list of comparators, and those are used by [mercury]
solver for multi-level sorting of GAVs in order to create the
optimization function. If no comparators are supplied, Mercury uses a
list of two default comparators: "shallowest", then "newest"
Thanks,
Oleg
Daniel
