|Re: Aggregator debate - take 2 [message #600226 is a reply to message #600209]
||Sat, 27 February 2010 10:15
| Filip Hrbek
Registered: July 2009
This was almost possible in my experimental implementation. I must say "almost" because the whole repository R1 was available|
to the final process for resolving dependencies. I guaranteed that the user got what explicitly selected, but
he could not control where the dependencies come from.
Repo A contains:
a.b.c/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
Repo B contains:
d.e.f/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
a.b.c/1.1.0.beta which depends on x.y.z/[1.0.0,1.5.0]
User A (in contribution A) requires
a.b.c/[1.0.0,MAX] defined under Repo A (he can see that the repo contains only 1.0.0, I think he expect this to be chosen)
User B (in contribution B) requires
d.e.f/[1.0.0,MAX] defined under Repo B (he can see that the repo contains only 1.0.0, I think he expect this to be chosen)
The result of the aggregation AS IT STANDS TODAY is:
a.b.c/1.1.0.beta from B - since it is the best match for A's request for a.b.c/[1.0.0,MAX]
d.e.f/1.0.0 from A - since it the best match of B's request for d.e.f/[1.0.0,MAX]
x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and d.e.f's dependency request
I think that user A may be surprised where a.b.c/1.1.0.beta comes from.
The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
a.b.c/1.1.0 from A - since it is the best match for A's request for a.b.c/[1.0.0,MAX] from the repository where user A defined his request
d.e.f/1.0.0 from A - since it the best match of B's request for d.e.f/[1.0.0,MAX] from the repository where user B defined his request
x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and d.e.f's dependency request, the scope for searching the dependencies is not limited
I think that with current model it should work like alg. 2).
If we say that alg. 1) is correct (I don't say it is incorrect!), then we should change the model and the UI.
In my view, both are correct! But then, we should change the model, the UI and add options to specify explicitly the scope of resolution. One of the algorithms becomes the default.
I would prefer to have a beer, a big table (not talking about software but real wooden table), a pen and a sheet of paper... and find the best solution :-)
Henrik Lindberg wrote:
> been thinking about this and wonder if the use case under debate is
> achieved by the following:
> - Repository R1 is mirrored to R2 and configured to only mirror
> component A (and what it requires).
> - In a second aggregation I use repository R2 and aggregate this with a
> bunch of other repositories.
> This way, my end result includes only the items I really wanted to get
> from R1.
> Will this handle the case Achim brought up?
> If so, how can the above be supported using only one aggregation?
> The extra repository creation step seems unnecessary to enable "cherry
> picking" - a use case that I think is not too uncommon.
> - henrik
Powered by FUDForum
. Page generated in 0.01605 seconds