| Aggregator with version range support [message #596320] |
Thu, 25 February 2010 17:21 |
 Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Hello,
I'd like to discuss the algorithm how the aggregator should resolve IU requests. This post is rather long but I wanted to express in detail what the problem is all about. I will appreciate you spending some time on it and helping me find a solution.
Background:
Let's have following aggregation definition:
Contribution A (contributed by user A)
|
+ Mapped Repository R1
|
+ IU Request: id=org.eclipse.myframework; version>=1.0.0
Contribution B (contributed by user B)
|
+ Mapped Repository R2
|
+ IU Request: id=org.eclipse.something.different; version>=1.0.0
Repository R1 contains:
org.eclipse.myframework/0.9.0.v20070415
org.eclipse.myframework/1.0.0.v20080105
org.eclipse.myframework/1.1.0.v20091220 (this is what user A expects)
Repository R2 contains:
org.eclipse.myframework/1.2.0.beta_for_testing_only (this is what user A does not expect and does not want at all)
org.eclipse.something.different/2.5.1.v20100225 (this is what user B expects)
=================================================
Now, what is the expected result? I think that a user would think probably like this:
The contribution "A" yields a version of "org.eclipse.myframework" that is the best from repository R1 and is not in conflict with any other contribution at the same time.
Since "org.eclipse.myframework" is not mapped in any other contribution, the natural resolution of it is "org.eclipse.myframework/1.1.0.v20091220".
The contribution "B" yields a version of "org.eclipse.something.different" that is the best from repository R1 and is not in conflict with any other contribution at the same time.
Since "org.eclipse.something.different" is not mapped in any other contribution, the natural resolution of it is "org.eclipse.something.different/2.5.1.v20100225".
The aggregated repository will contain:
org.eclipse.myframework/1.1.0.v20091220
org.eclipse.something.different/2.5.1.v20100225
OK?
However, the new aggregator (with version range support) will create an aggregated repository containing:
org.eclipse.myframework/1.2.0.beta_for_testing_only
org.eclipse.something.different/2.5.1.v20100225
The reason why "1.2.0.beta_for_testing_only" was chosen is simple: We use a request accross all repositories, regardless where the IU was mapped.
In my view, this is bad.
That's why I tried to change the algorithm:
For each IU request
1) Resolve the request against its parent mapped repository (first level only, no dependencies) and get a set of matching resolutions
2) Create a modified IU request that defines the IU name and version enumeration (of matching resolutions) instead of the original version range
3) Provide the modified request to the global aggregated repository processing
This way, only IUs that are really present in appropriate mapped repository may be passed to the final resolution.
So far so good, but the problem is that the only implementation of IRequirement is the RequiredCapability which does not support version constraints different from version ranges.
As a proof of concept, I tried to hack this all so that the interim repository supports another implementation of IRequirement with more complex version constraints. It works as expected!
Finally, the questions to answer:
1) Do you think that this approach is nature/logical, i.e. is it how it should work?
2) If the answer to 1) is YES, then we need to think about how to do it without too much hacking (I can provide more details on what all I had to do and what I don't like on the "hacking solution")
Current b3 aggregator (available on the b3 update site) uses the "hacking solution" which should later be removed or replaced with something better. This is now there for testing purpose only.
The cleanest solution would be to suggest support for complex version constraints in any p2 repository, but I am afraid that it would be a big problem because of compatibility (old p2 clients would not be able to read all new p2 repos).
PS: Support for complex version constraints would allow us to implement what Henrik has mentioned in one of our discussions - "User wants to map versions from 1.0.0 to 2.0.0 but not 1.3.4 which is known to be buggy"
Thanks for your patience, comments, questions and ideas :-)
Best regards
Filip
|
|
|
Powered by
FUDForum. Page generated in 0.03829 seconds
] 
Search
Help
Register
Login
Home
