Community
Participate
Working Groups
The behavior of p2 planner in the following use case does not seem to be correct. Use case: 1) use the planner to create a profile change request which contains feature A for install and provision this change request 2) create and provision a profile change request where the installed version of feature A is added for install and for uninstall. 3) uninstall feature A. The result of these tree operation is: * feature A is uninstalled. * all bundles which feature A includes are removed from the p2 profile but they are still listed in the bundles.info. What happens is that during the operation 2) the inclusion rules of feature A are removed from the p2 profile which has the side effect that all bundles installed with feature A are still listed in the bundles.info after feature A is uninstalled. IMHO planner should be able to deal with this use case and it is a valid use of planner's APIs. Workaround is of course to filter all IUs which don't need to be uninstalled but why I need the planner then. I will attach a test case to this bug which reproduces this bug.
Created attachment 204862 [details] Test case to reproduce this bug
Pascal, thank you for pointing to this fix (http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=37df25467c3b5a333c6c7993836723da05d9e8e1). It's indeed related to current issue though it seems it's not enough to fix it - the IUs are handled properly but there is a problem with the properties of those IUs which are both added and removed. I guess what's done for IUs here: SimplePlanner#computeActualChangeRequest(Collection<IInstallableUnit> toState, ProfileChangeRequest changeRequest) { Collection<IInstallableUnit> requestedAdditions = changeRequest.getAdditions; Collection<IInstallableUnit> requestedRemovals = new ArrayList<IInstallableUnit>(changeRequest.getRemovals()); requestedRemovals.removeAll(requestedAdditions); should be done for the properties here: SimplePlanner#planPropertyOperations - remove all allIUPropertyChanges that exist in allIUPropertyDeletions I'm not very familiar with how properties should be handled so could you please take a look at it and tell me what you think?
Created attachment 205363 [details] Test case for this bug updated
Created attachment 205366 [details] Prevents removal of profile properties This patch just prevents the removal of profile properties for IUs which exists as additions and removals in a profile change request.
Created attachment 206538 [details] test case update
Created attachment 206539 [details] Another optin to patch this bug Ian and I created a second option to fix this bug. This is a more general way to fix it and requires a little bit more changes.
Thanks Beyhan, I thought a bit more about this on my way home -- and also talked with Pascal on the Equinox/p2 call. While this does make the code a little nicer (one fix instead of two), it mutates the PCR, and this might have unwanted side effects. I'll see if I can improve this a bit tomorrow.
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. -- The automated Eclipse Genie.
