Closed laeubi closed 9 months ago
So finally the slicer would select the highest version? That would be really nice
it depends a bit, be aware that we are talking about p2 units, but a requirement can be anything (e.g. a package) so if two bundles with different name provide the same package still both are used because we can't know what is "the highest" and highest is not always best, so I'm just offering this here as a way to evaluate this more.
Another approach would be to make the slicer more extensible and let the user decide...
6 files - 3 6 suites - 3 34m 7s :stopwatch: +14s 2 067 tests - 116 2 056 :white_check_mark: - 123 1 :zzz: - 3 4 :x: + 4 6 :fire: + 6 6 291 runs - 348 6 259 :white_check_mark: - 369 2 :zzz: - 9 12 :x: +12 18 :fire: +18
For more details on these failures and errors, see this check.
Results for commit 5c310106. ± Comparison against base commit 61dd7059.
And as we see this fails some tests already :-\
I'll wait for @merks review here and probably downgrade to the "more extensible" approach then...
I have a feeling there is an assumption here that a requirement is necessarily selecting IUs with the same BSN. But a requirement could be a package requirement and it could select IUs with different BSN. Also that's the case for properties matches...
Hmmm. I think the group by is dealing with that.
Hmmm. I think the group by is dealing with that.
Yes but it seems not working, I get the impression that one would need a two step approach here:
1) slice like today 2) preprocess (e.g. with a planner like) that decides if there are units that are effectively unreachable or some kind of duplicate filtering ... I think I'll drop this for now as it seems not really an easy win.
@vogella If you have an issue with duplicate items with the target platform please open an issue at PDE with a reproducer.
Currently if the slicer is given a set of IUs where multiple ones match a requirement, all of them are selected independently of the actual number of max constraint.
This is now changed by collecting all IUs that satisfy the requirement, then sort them by highest version and restrict the result to the maximum number per id.
Important: This potentially can change the behavior of the slicer! So it might be good to test it with some different use cases.