Community
Participate
Working Groups
With 3.4RC3: - I have mylyin in an extension location using a link file - I update -> The new plugins are not used
for a flash demo see: http://scharf.gr/eclipse/bugs/Bug_235156/
I think this is a recent regression that has likely been introduced when we changed the code that computes the provisioning plan (bug 234186). What happens is as follow: - user installs GEF in the dropins, the roots gets marked as "installed from dropins". - user updates GEF from the ganymede update site. A new version gets downloaded and installed. During this process the new IUs are installed as updates of the original one. Therefore the IU properties get transfered to the new IUs. So the IUs that the user installed get marked as "installed from dropins" where in reality they have been explicitly installed. - next restart, the dropins kicks and believes that the new version of GEF that the user installed is something that got installed by the dropins (since it has the property) and therefore it gets removed since it does not appear in the repository we are synchronizing with.
Created attachment 103242 [details] Attempt at fixing the problem I have hacked this up and with it, I can confirm that the update of GEF stays around. The logic behind the patch is that something that has been installed by the dropins can only have as valid IU Properties the combination "installed from dropins" and "optional". Therefore in case where the "dropins" property is detected and the install mode is "Strict", it means that something else installed this new copy and therefore the "dropins" property can be removed. Obviously this does not handle more complex scenario where GEF would be updated as part of another upgrade with flexible dependencies (e.g. GMF depending loosely on GEF) but still handle a large number of scenario. This problem is unfortunately important since it means that we will not be able to update the EPP packages since they are created from a dropins operation :-(
Created attachment 103378 [details] patch Updated patch... same code just added comments describing the problem. Pascal and I talked about this and we believe that it is the best solution at this point in time. The case that it doesn't handle 100% is where the features contain non-singleton or differing bundles. Consider the following: - Feature FFF v1.0 contains bundle BBB - Feature FFF v2.0 contains bundle CCC Scenario is as follows: - If you drop FFF v1.0 into the dropins, then FFF and BB get installed. - Then if you do an update, we install FFF v2.0 and CCC. - In the ProfileSynchronizer we detect that FFF v2.0 was installed from the UI but it also has the "from dropins" property on it so we remove that property. - FFF v1.0 is uninstalled because it is optional (default attribute when coming from the dropins) - BBB is NOT uninstalled: this is the problem The problem stems from the fact that we install everything and Classic Update Manager had features as its installable unit. We discussed this and feel that it is something we can live with for 1.0.
Adding John and Pascal as Component Lead and Reviewers as per the 3.4 endgame plan.
Adding Boris as additional component lead.
cc'ing Tom as component lead.
+1 to fixing this in 3.4.0. I will depend on the review of Pascal and John as to the correct fix since I am not familiar with the code. I am wandering if there are constants somewhere for the strings "STRICT" and "org.eclipse.equinox.p2.internal.inclusion.rules". If not then you should mark these with $NON-NLS tags at least.
I have already reviewed the patch, but it seems that this has somewhat been lost.
Try it again Pascal, I may have +'ed the wrong name.
+1. I verified by adding an old version of RSE in my dropins. I was able to upgrade to the new version in the Ganymede repository and the new version was running after restart.
Released.
Reopening. There is still a problem here. We also need to remove the PROP_PROFILE_LOCKED_IU property in this case. Otherwise, I can never uninstall the thing that I upgraded. I.e., to test the patch I installed something in dropins, then upgraded with p2. This worked, but now there is no way to uninstall the upgraded feature.
Created attachment 103737 [details] Patch removing the locked property
John, Tom, DJ, please review.
+1 to fixing this.
+1. I retested with the latest patch, and I am able to upgrade features from dropins, and then uninstall the upgrade and revert to the version from dropins. The lock property is correctly added back when I revert to the version in dropins.
Thanks for the fix! It works now.
