Community
Participate
Working Groups
Created attachment 126629 [details] HelloWorldSite Build ID: I20090202-1535 Steps To Reproduce: Using RHEL 5.2 and eclipse 3.5 I20090202-1535 1. Unzip SDK to /opt/eclipse35_0202 2. Launch root user with command ./eclipse -data /root/test1/workspace -vm /opt/ibm/java-i386-60/bin/java 3. Install HelloWorld version 1.0.0 using p2 UI 4. Restart SDK 5. Verify HelloWorld version 1.0.0 is installed using p2 UI 6. Login as an ordinary user, tester1, and launch command ./eclipse -data $HOME/test1/workspace -configuration $HOME/test1/configuration -vm /opt/ibm/java-i386-60/bin/java 7. Verify HelloWorld is available using p2 UI 8. Add HelloWorldSite to tester1 repositories 9. All versions of site show available including 1.0.0 that is in shared. 10. Install version 1.1.0. and verify it is 1.1.0 loading. Great! 11. Verify root still loads 1.0.0. Great! 12. As root, uninstall version 1.0.0. More information: tester1 does not have the 1.1.0 bundle loaded that he provisioned. His private bundles.info does not have any version of HelloWorld.
Simon, I thought this should have been handled in our shared install cases. Is this a regression or is there a miss configuration going on. Do we have a automated test for this?
We do not currently have an automated test case for this exact use case. It still sounds a bit strange to me but it's possible we somehow aren't looking after the existing roots when we resynch with the updated shared profile. Jim is that HelloWorld bundle a singleton? Would it be possible to confirm that the 1.1 HelloWorld was in the user's bundle.info immediately before starting (e.g. write before starting the user install after removing 1.0 from the shared install - step 13(?)) This would help narrow the problem down to a re-synch issue.
Yes, I checked and it is a singleton. Does that matter since we only have one enabled for the user configuration and one for the root configuration. I will double check to see if the HelloWorld 1.l is in the user's bundle pool.
Yes 1.1 is installed into the user's bundle pool and referenced by bundles.info
> Yes, I checked and it is a singleton. Does that matter ... Indeed it does. You were able to install the 1.1 version of Helloworld because of a glitch in the UI. You might have noticed that if you tried to "update" the 1.0 version of Helloworld it wouldn't let you. When you select install the UI figures you meant to upgrade the bundle and circumvents one of the locking checks we have. Sadly the locking check is superficial in that it is only a UI thing. The reason the 1.1 version goes away is that when we upgraded the Helloworld bundle we also moved a special "BASE" iu property to the new version. We use "BASE" to track root ius that belong to the base profile. In SurrogateProfile.updateProfile when a change is detected we re-synch the "BASE" ius and in your case since the Helloworld bundle is no longer part of the base profile we remove it. Words probably don't adequately describe what's going on here but if you trace through SurrogateProfileHandler.updateProfile and then ProfileSynchronizer.synchronize you can see first hand what's happening. I seem to remember logging this in 3.4 so I'll see if I can't find the original bug.
The UI bug was bug 231200 <Note: Pascal that bug is not currently targeted and I didn't alter thatt> For more formal support for locking IUs see bug 227688 *** This bug has been marked as a duplicate of bug 231200 ***
I need more information and I think this is a better place to discuss than in the bug that it was dupped to. We can redup later. Please describe the external behavior at a functional level - Is the behavior different for a singleton plugin and a non singleton. Since I am not trying to enable 2 different versions of bundles I would not have expected this to be a problem. - Are we saying a user can't do anything to modify the version of features installed by the admin? Please note we are not using the same configuration space. What is the controlling artifact for this? - Will this behavior be different when we don't use the shared configuration? - What are the limitations when using the API? Are they the same as when using the p2 UI. I am more interested in a description of the design intended and not the behaviors that are not working correctly.
On on RHEL 5.2 this works in 0415-1348 which has the bug 231200 fix. The behavior is to not allow the user to upgrade though the install or update panels. I am going to check on Vista before I suggest that this is resolved.
This works correctly on vista also. This bug can be marked resolved or dupped to original bug. Thanks. *** This bug has been marked as a duplicate of bug 231200 ***
