Pascal,
Pascal Rapicault wrote:
Hi Oleg,
I'm glad to hear from you and your team. Trying to unify/share is
definitely interesting and after taking a brief look at the goals of
Mercury, I think there is place for an even bigger collaboration than
just at the dependency resolution level. For example transport,
repository API, version range mgt, etc. and even probably higher up,
but we should talk about that someplace else. Will you or anyone from
your group attend EclipseCon?
This is awesome! We will be there, let's schedule some time to talk
about this. For example: OSGi spec's v=1.2.3 => { x | x >= 1.2.3
} is probably justifiable, but is too resource consuming in practical
application, so in Mercury it's configurable. We'll sure chat about
these things.
Now when it comes down to resolution, I agree that there is an
even larger potential for collaboration and we should explore this
opportunity seriously. I initially designed p2 metadata with the goal
of being able to express any kind of dependency that could be found out
there, unfortunately I got caught back by the reality of shipping p2 in
3.4 and since then I never got much time to focus on this again. So I'm
definitely excited to the idea of continuing this work and see this
potential collaboration to finish this up for good :) A few things that
I had in mind relied around _expression_ of negation, or'ing, removal of
singleton as a special concept, use of dependency on something else
than version ranges, etc.
Once we have a system of linear inequations, adding expressions on top
of that is trivial. So I think a good, solid dependency _expression_
language and it's resolution should be the first practical step. Once
we have that - it's all downhill from there :)
Cheers,
Oleg
> On the side issue: P2 uses an indirect way of creating those
inequations
> - creates a file and then feeds it to solver. In Mercury we took a
> different approach and bypass file stage, feeding expressions
directly
> to the solver, which is more efficient. If you'd like we can work
> together to fix that.
I think Daniel covered that one. This is work in progress in a
branch that will find its way in the main codebase in 3.5.
The main reason for using an opb file was to ease the debugging
and also run our encoding against other opb solvers to compare perfs
etc.
PaScaL
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|