Community
Participate
Working Groups
Build Version: 3.7.0 Build id: I20100730-0800 Consider the following: - Feature F v1.0 includes Bundle B v1.0. - Feature Patch FP v2.0 patches F v1.0 and includes B v2.0. - Feature Patch FP v3.0 patches F v1.0 and includes B v3.0. Setup: - install F v1.0 and B v1.0 via dropins - install FP v2.0 and B v2.0 via dropins Now if you install FP v3.0 and B v3.0 via dropins everything works fine and they get installed. But if you try and install FP v3.0 and B v3.0 via the p2 UI then it appears to work but when you restart and look at what is installed, they aren't there. Shouldn't we be able to update things installed via the dropins, through the UI?
(In reply to comment #0) > Shouldn't we be able to update things installed via the dropins, through the > UI? I've heard NO. That is, if you install something via dropins then you now manage that entirely on your own. Having said that, I don't really see why this won't work. Assuming that the provisioning operation was successful, the bundles.info should be updated to point to B v3.0, and it 'should' work.
The update of feature patch (initially installed via dropins) is succesful, plan generated by p2 is correct and feature patch is updated properly and included in bundles.info. After restart p2.reconciler.dropins plugin synchronizes configuration. In ProfileSynchronizer#createProfileChangeRequest newly installed feature patch is being added to "toRemove" list. This is caused by the fact that Collector allIUs = getAllIUsFromRepos(); allIUs does not contain new feature patch that during installation has been copied to features/ and plugins/. Collector dropinIUs = profile.query(new IUProfilePropertyQuery(profile, PROP_FROM_DROPINS, Boolean.toString(true)), new Collector(), null); dropinsIUs contains this feature patch. And next: if (all.contains(iu)) toAdd.remove(iu); else toRemove.add(iu); newly installed feature patch is on toRemove list. I tested this scenario with ordinary feature (not a feature patch) and the feature is also not included in allIUs. However, feature installed via p2 user interface is marked as STRICT, so below statement: if ("STRICT".equals(profile.getInstallableUnitProperty(iu, "org.eclipse.equinox.p2.internal.inclusion.rules"))){ request.removeInstallableUnitProfileProperty(iu, PROP_FROM_DROPINS); request.removeInstallableUnitProfileProperty(iu, IProfile.PROP_PROFILE_LOCKED_IU); continue; } prevents it from being in toRemove list. As I see there is no way to distinct feature patches installed via user interface and via dropins cause patches are always OPTIONAL. Here are my thoughts about this situation: 1) Shouldn't newly installed feature (or feature patch) that is already included in bundle pool be present in repositories that ProfileSynchronizer checks? Maybe repositories should be reloaded before? 2) I tried to modify lines in case iu is a patch: if (all.contains(iu)) toAdd.remove(iu); else if (!QueryUtil.isPatch(iu)) toRemove.add(iu); As a result profile change request doesn't include new feature patch in removals, however p2 still returns plan, when the older version of feature patch (the one from dropins) is being installed and the newer one (with higher version) is being unistalled.
I think that we just need a way to distinguish feature patch updated with p2 user interface from feature patch updated via dropins. Now installable units installed/updated via UI are marked as 'STRICT', but this rule doesn't work for patches. Pascal, maybe there should be a new property introduced for patches updated via user interface?
Interesting, using the latest I-build I get the following error message from SAT4J. (in this case ccc is the bundle included in the 2nd version of the feature patch) !ENTRY org.eclipse.equinox.p2.ui 4 0 2010-09-15 11:23:35.450 !MESSAGE ccc 1.0.0 is unknown in the solver! !STACK 0 java.lang.IllegalArgumentException: ccc 1.0.0 is unknown in the solver! at org.sat4j.pb.tools.DependencyHelper.getIntValue(Unknown Source) at org.sat4j.pb.tools.DependencyHelper.getBooleanValueFor(Unknown Source) at org.eclipse.equinox.internal.p2.director.Projector.getFragmentAssociation(Projector.java:1174) at org.eclipse.equinox.internal.p2.director.SimplePlanner.getProvisioningPlan(SimplePlanner.java:381) at org.eclipse.equinox.internal.p2.operations.PlannerResolutionJob.runModal(PlannerResolutionJob.java:76) at org.eclipse.equinox.p2.operations.ProfileChangeOperation.resolveModal(ProfileChangeOperation.java:115) at org.eclipse.equinox.internal.p2.ui.dialogs.ProvisioningOperationWizard$1.run(ProvisioningOperationWizard.java:207) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Cancel my last comment. I've re-generated my test data and I get the same behaviour as we had before now. Not sure what the problem was with my last set of test data.
Changing summary to reflect real issue. As Ian mentions in comment #1, the current policy is that if the user installs things via the dropins mechanism, then it is up to the user to manage those bundles/features. So the question becomes: - is this something we want to change? - if yes, then how? Pascal, if we decided to add a new property especially for patches which are installed via the UI, how complicated would the changes be in the Projector? I assume this would change the way things are encoded before being passed to SAT4J.
Nothing will happen on this.
