Community
Participate
Working Groups
Details to come.
Created attachment 127927 [details] patch Patch for the director version 1.0.4.v20081112-1019.
Created attachment 127928 [details] new director jar for R34x new director JAR
Created attachment 127929 [details] patch for HEAD Initial patch for HEAD. Note Pascal said that we still have to consider the patches higher than the IUs recommended to install. With this patch there are still 2 test failures: junit.framework.AssertionFailedError: Can't find RPT_ARM_TEST.feature.group 1.0.0 in the plan at junit.framework.Assert.fail(Assert.java:47) at org.eclipse.equinox.p2.tests.AbstractProvisioningTest.assertInstallOperand(AbstractProvisioningTest.java:824) at org.eclipse.equinox.p2.tests.planner.Bug254481dataSet1.testInstallFeaturePatch(Bug254481dataSet1.java:44) junit.framework.AssertionFailedError: Can't find org.eclipse.jdt.feature.patch.feature.group 1.0.0 in the plan at junit.framework.Assert.fail(Assert.java:47) at org.eclipse.equinox.p2.tests.AbstractProvisioningTest.assertInstallOperand(AbstractProvisioningTest.java:824) at org.eclipse.equinox.p2.tests.planner.Bug254481dataSet2.testInstallFeaturePatch(Bug254481dataSet2.java:44)
Created attachment 127931 [details] patch for HEAD New patch for HEAD. All tests pass.
Patch committed to HEAD.
Created attachment 127932 [details] new director jar for R34x new JAR for the director for the R34x stream.
Created attachment 127936 [details] New patch for 3.4.x The initial fix was giving a higher priority to all optional pieces requested for installation, however patches needs to have a higher priority to ensure their installation (bug #254481). This fixes guarantees that patches requested for installation receive a higher priority than other optional things requested for installation.
Created attachment 127938 [details] New binary version of director for R34x
Some background on the problem. For the solver to find a stable solution in presence of a non fully constrained problem (e.g. there are open version range [1.0, 2.0)) , p2 provides the solver an optimization function. In 3.4 and 3.5 this optimization function favors the highest version of an available plug-in. When this optimization function is combined with an installation where all plug-ins are installed optionally, it can cause some of the non optional pieces to be not installed because there is a plug-in with a higher version that would result in a more optimal solution. An example of such a situation is Initial state A2 -> B2 C -> B[1,3) We are uninstalling A2 to replace it with A1 (and A1 depends on B1). Because C has a dependency on B that is unconstrained, B2 is brought in to potentially be part of the solution. When the solver looks for the solution it favors B2 and can do so because not installing A1 is possible (it is not required for a successful solution since it is optional), thus causing B1 to not be installed. A1 -> B1 C -> B[1,3) I think that what is wrong in the current approach is that the user's request to optionally install something should always take precedence over the search for the most recent plug-in since it is the user's desire. To some degree this is similar to the problem we have had with the bug #254481 where patches were sometimes not installed.
Fix released in HEAD and 3.4 maintenance. Keeping open to add a regression tests smaller than the real use case.
Bug# 276133 is a consequence of that patch.
