Community
Participate
Working Groups
As requested on p2-dev mailing list this issue is reported as p2 bug. Tycho is using the org.eclipse.equinox.internal.p2.director.Projector under the assumption that the projector will always prefer the latest version of a dependency with unspecified version constraint. Attached to bug 352081 there is an example for the resolver not preferring the highest available version.
There is another reported case with Tycho, where this behaviour occurs: bug 365962. I have tried to debug it in Tycho and found out that any higher version solution will not be taken as soon as its size (in terms of all required IUs) is two or more IUs larger than that of the older version. Higher version solution, which is only one IU larger, will be always preferred against the older version. See mentioned bugzilla for a minimal example. I believe, solution size is generally a desirable factor in determining the final choice of problem solution. However, in specific use cases, like picking up the latest available version of a dependency during the build, this might lead to unexpected erroneous behaviour, whose origin is not always easily recognizable. Workarounds to this problem would place additional constraints to the build structure and scoping which would otherwise not apply. Therefore I think it should be possible to make solution size optimization optional and allow the client to disable it if needed.
Hi Wladimir, This is indeed a problem we have because planning which IUs should be installed is multi-criteria: - we want to avoid installing non necessary IUs, thus each IU has a penalty (a positive weight) - we want most up to date packages when possible. Most recent IUs have a smaller penalty than older IUs. Those individual weighting schemes are ok But when you sum up everything, the global penalty of your installation can be smaller with some older IUs than with newer ones. That's the limit of the approach. We could decide that if new IUs are available for IUs we try to install, they must be used, and adjust the weighting scheme to that new rule. Or we could put a flag that provides that feature on demand. What is the number of dependant IUs that are added with the most recents IUs in your context?
(In reply to comment #2) > We could decide that if new IUs are available for IUs we try to install, they > must be used, and adjust the weighting scheme to that new rule. > > Or we could put a flag that provides that feature on demand. > > What is the number of dependant IUs that are added with the most recents IUs > in your context? Hi Daniel, thanks for your comment. I used very simple dependency schema in my example. Older version has no dependencies, newer version has two dependencies. Older version was preferred. If I removed one of the dependencies from the newer version, it was preferred as expected. So therefore I came to an assumption that starting from two IUs diff the newer version is not preferred anymore. I am not sure if the current strategy and its behaviour in case of two alternative versions with different solution sizes is at all important to have for some reason. After all, having newer version is generally always desirable. I think, this should be discussed with others. From my point of view, the best would be to use your suggested approach: always try to install new IUs if available. Alternatively, a flag for providing this feature on demand would also make it. As far as I can see it, it would really fix problems with Tycho. I hope, some of Tycho developers could comment on this.
(In reply to comment #2) > We could decide that if new IUs are available for IUs we try to install, they > must be used, and adjust the weighting scheme to that new rule. Is this possible at all? For this to work, we need a high penalty on old versions, and a low penalty on the installing something. But what if installing the latest version of bundle A entails that an old version bundle B needs to be installed? I imagine that addressing this is very complicated and requires staggered penalties (decreasing with the minimum distance from the roots?)...
Tobias, Yes, it is not a trivial change. But there are ways to do it. For instance, we make sure currently that patches are applied even if they entail to install a lot of IUs. We just need to have a clear picture of what is expected, and we can adapt the weights in such a way that some IUs are strictly preferred to the other ones. (Sat4j uses arbitrary precision arithmetics to allow such behavior).
*** Bug 418546 has been marked as a duplicate of this bug. ***
I'm not sure how this issue could be solved. It's complex and there no active participants in the process. Probably everyone got annoyed from lack of any sort of progress.
I think this should be closed as wontfix because: - there is workaround which consists in specifying a requirement on the IU of highest version which will force it be part of the solution; - there is very few resource to work on this, and the impact of the change could be pretty large
Yes, I imagine that any changes that alters the current "default" behavior will just cause problems for other things that relying on the current behavior. If there could be "options" to tweak/configure the behavior, that would be another story, but who is going to work on that? Without a focused contribution toward such a goal, it's just not going to happen. And of course reviewing, testing and maintaining contributions is also not without additional cost.
