Community
Participate
Working Groups
When I look at the IPlanner class, the updatesFor method seems to be out of place since it is only a fancy query. Now two possibilities: - if we believe this could be something that eventually could make use of the resolver, then we keep it - if we want to keep it as a simple query for now, we could move it out in a more appropriate place.
Interesting question. I think that this is probably just a query. Having the resolver eliminate updates that are incompatible with the user's profile sounds nice on the surface, but in scenarios with a UI, we would probably want the user to know that these updates existed and couldn't be installed. So the UI would probably want to use the query all the time, and then resolve for particular combinations of updates. Do we think there's a headless use case where resolving for the latest compatible updates is necessary?
See also bug 273967. The UI finds out what updates are available, but currently queries each individual IU for updates so that it can keep track of which update belongs to which IU. It is not necessarily obvious the relationship between an IU and its updates now that patches are considered as updates. It would be nice if the updatesFor method returned some kind of data structure that mapped the update to the IU for which it is updating. This way, the UI could get updatesFor the entire profile and not have to go back and query the items individually. Obviously the planner has this information in hand when it is finding the updates.
Some other considerations: - since updates can now include patches, it's possible that planner.updatesFor returns something already installed. If IU "A" has a patch "PatchForA," and that patch is installed, checking for updates to A will include PatchForA. This was the situation in bug 273967. Presumably checking for updates for {A, PatchForA} would catch this case, but I'm not really sure that's true (didn't try it). So this is perhaps a case to do some kind of resolve when updates are being searched, or at least to consider the installed software of the profile, or perhaps just clarify the behavior. - patches do not have an update descriptor. So they are returned by updatesFor, but don't truly look like updates. This means the UI can't simply get the descriptor and figure out what the update applies to. For patches, I'm not even sure what API to use to figure out which IU a patch belongs to. It might be useful to have helper methods in this area. (In reply to comment #1) > Do we think there's a headless use case where resolving for the latest > compatible updates is necessary? I think there is a use case for this. It's the same one shown in org.eclipse.equinox.p2.examples.rcp.prestartupdate. The app queries for updates and updates itself as it starts. It is now out of date with respect to patches. The code that "does the right thing" wrt patches and updates is consolidated currently in UpdateWizard.createProfileChangeRequest(...) It's fairly complicated. I think one goal in revisiting the planner API should be that there is at least a helper that would assemble the right collection of updates and patches (the latest available) similar to what is done in this method.
(In reply to comment #3) >The code that "does the right thing" wrt patches and updates is > consolidated currently in > UpdateWizard.createProfileChangeRequest(...) > It's fairly complicated. > > I think one goal in revisiting the planner API should be that there is at least > a helper that would assemble the right collection of updates and patches (the > latest available) similar to what is done in this method. The code mentioned in the previous comment now lives in UpdateOperation
I have marked the method with @noreference for now.
Given the "follow transitive closure of requirements" done by the solver released for bug 259537, this API is looking more and more like API that has to include the resolver.... I opened a new bug for this (bug 313979) because I think there are UI-level issues at play, too. It seems like updatesFor: might be both a fancy query (the query determines how deep you are looking), but the resolver might also be involved??
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
I don't see that anything actionable remains for this item.
