[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Dependency management synergies

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