Community
Participate
Working Groups
From bug 222945, as I install feature patches they do not show up in the available software dialog. However, when I open the revert configuration dialog, they show up as being in the previous configs. At one point, I installed the same patch twice in a row and it showed up in the dialog. I am running against N20080927-2000. Sorry that I don't have good steps to reproduce. Once 222945 is released (probably after the p2 ui changes next week), this issue will be much easier to reproduce.
Susan, Curtis is using the InstallAction#computeProvisioningPlan(...) method to install the patches. Would it be possible that the root property is not set?
When I was debugging through the creation of the provisioning plan, the InstallAction did correctly set the root property using: request.setInstallableUnitProfileProperty(ius[i], IInstallableUnit.PROP_PROFILE_ROOT_IU, Boolean.toString(true)); Though often the patch was being updated, not installed, I still think it added the root property whenever I was debugging through it.
Looking at the code, I don't see why the root property would not get set. This method takes care to set it whenever it adds it to the profile. And if it is showing in the revert wizard, then it was set when the snapshot was taken. Just to step back a moment... >From bug 222945, as I install feature patches they do not show up in the >available software dialog. However, when I open the revert configuration did you really mean available software dialog? I assume you would mean the installed view. I need to understand the scenario better.
Yes, they don't show up on the installed software list. Well technically they don't show up in the available software tab either, under a repo site that contains many patches, but that would be expected because only features show up there :) This will be a lot easier to demonstrate once we have an I build, because you can try out the new one-click export and install feature to reproduce. As part of that feature an IUPatch gets installed. After installation/restart, the patch may or may not show up in the Installed Software View. I would prefer it if they always showed up.
I'll look at this once our various stuff is integrated after this i-build, after I release my branch work.
I can reproduce this. It happens "every other time" you export the same plug-in. The first time you export a plug-in, it does an install, and the profile root property gets set correctly. The second time you export the plug-in, the UI InstallAction recognizes the request to install the patch as an implied upgrade of the patch. Because the original patch had the root property set, the InstallAction doesn't set it, relying on the upgrade process to handle it. But for some reason the profile property is not transferred. The third time you export the plug-in, the InstallAction again recognizes an implied upgrade, and since the patch no longer has the root property set, the action requests it to be set in the profile change request. I talked to Simon about this. Theory is that either: 1) the planner is not building an upgrade operand but instead is removing and adding the IU. Simon said he and DJ noticed something funny in the planner code related to updates. 2) the planner builds the upgrade operand correctly but for some reason the engine is not transferring the profile property. I'll debug this and report back.
It looks like the problem is the operands generated by the planner. In my example, the UI builds a profile change request to remove org.eclipse.equinox.p2.ui.sdk 1.0.100.200810151006 add org.eclipse.equinox.p2.ui.sdk 1.0.100.200810151026 The planner generates three operands. The first one looks correct, but then it is followed by extra operands to remove and reinstall the patch [[R]org.eclipse.equinox.p2.ui.sdk 1.0.100.200810151006 --> [R]org.eclipse.equinox.p2.ui.sdk 1.0.100.200810151026, [R]org.eclipse.equinox.p2.ui.sdk.patch 1.0.0.200810151006 --> null, null --> [R]org.eclipse.equinox.p2.ui.sdk.patch 1.0.0.200810151026]
Reassigning to Pascal for further investigation. cc'ing DJ as Simon mentioned that he has seen this problem.
Changing the target milestone as we are not contributing to M3. However please make sure these bugs are addressed early in M4 or tomorrow Testing Thursday for the test related ones.
*** This bug has been marked as a duplicate of bug 248468 ***
Susan, despite the fix, there may still be another problem in the UI. Please confirm on your side. Thx.
(In reply to comment #11) > Susan, despite the fix, there may still be another problem in the UI. Please > confirm on your side. Thx. > I would be surprised if this were the case. When I debugged this, the UI was building the expected/correct profile change request, so if the planner has been fixed, it should work. Reopening so it can be checked against the next nightly build.
> > Reopening so it can be checked against the next nightly build. > Rechecked on WinXP, I20081112-1200. The symptom is exactly as described in comment #6, so I suspect the problem is still as theorized in that comment. I won't have time to debug this further until next week...if anyone else wants to look at it in the meantime feel free, as I'm pretty confident this is not the UI.
Having trouble debugging this on my current build, I wasn't able to restart after applying a simple patch to the workbench UI. So I'll try it on a clean build/M4 candidate. Marking M5 since I won't be fixing anything. I still believe that this is a planner problem or some other non-UI issue.
I just tried this again and it works. I think it got fixed in the planner sometime along the way. I patched a project 4 times...each time it patched the environment correctly and shows the patch in the Installed Software list.
