Bugzilla – Full Text Bug Listing
| Summary: | [ui] Updated locked iu by using install | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Simon Kaegi <simon_kaegi> | ||||||||||
| Component: | p2 | Assignee: | Susan McCourt <susan> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | jdmiles, john.arthorne, overholt, pascal, susan | ||||||||||
| Version: | 3.4 | ||||||||||||
| Target Milestone: | 3.5 M7 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 227688 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Simon Kaegi
Good point. The code I added for bug #229877 implies an update from the install, but the install action only checked for the install lock. Once it decides to assume an update, it should check the update lock. Shouldn't this fail at the planner level because the two versions have conflicting requirements on singleton bundles? I.e., you can't really install a newer build without uninstalling the old one. per bug #229877 (see discussion and screen snaps), the UI will recognize you are trying to an install a newer one and infer an upgrade. It will tell you that it is going to upgrade (you can cancel the wizard if that was not the intention) and submits an upgrade plan to the planner. That is where it should check the update lock. Hmmm...looking for opinions on how to handle this case when the locked IU is not already an install root. The scenario is this: - user selects a later version of something already installed and says "install" - the install action notices this is actually an implied upgrade - normal mode of operation (per bug 229877) is to go ahead with the upgrade and tell the user that this is an upgrade, not an install. Everything is fine. Now, we find that the IU is locked for update. I can simply tell the user "Already installed. Update not permitted. This makes sense if it was already an install root, and they knew it was installed. But if it's not an install root, and they don't know it's already installed...telling them it can't be updated is confusing. They will go to the installed software list and not see it and open a bug. A similar issue that we handle correctly is when the user selects the same version as what they have and tries to install. If it was already a root, we tell them "already installed." But if it wasn't a root, we build a plan that will mark it as a root. This way the user now sees that it's installed, and it simply feels like a really fast install. But in this "locked upgrade case", I can't simply mark what they already have as a root or it will look like we chose to install a different (older) version than they asked for. Options: a) just tell them an older version is installed and can't be upgraded. They will be confused because they don't see it in the list b) tell them that only the older version can be installed and if they continue with the operation we mark it as a root so they will see it. Kind of sneaky because it is actually already installed and continuing the user action only marks it visible. But this may be the right thing to do since they have apparently become interested in this IU and would want to be reassured that they have it installed? Created attachment 99745 [details]
patch for checking update lock
This is a work in progress which currently tells the user that the IU is already installed (even if it was not marked a root).
Currently we are not locking the SDK in the build, so this patch wouldn't really matter. For that reason I'm moving this bug to RC2 and will reinvestigate once our locking strategy for 3.4 is decided.
looks like we won't be setting locks for 3.4 (too late) so this bug can be deferred. *** Bug 266044 has been marked as a duplicate of this bug. *** Susan, can I work through this one with you; I'd really like to see it fixed for 3.5. The only situation I really would like to protect against in the IU is the case where an install of a later version of a locked root IU is being promoted to an upgrade. This should be pretty trivial to fix now. My concerns in comment #4 (how to tell the user it's already locked if it's not a root) have already been handled for other cases. Since M5, we tell the user that "parts of X" are already installed, so I think this is just a simple UI change and status message now. I'll ping you if I need you Simon. Created attachment 129006 [details]
patch
here's a patch against HEAD for Simon's testing.
Created attachment 129264 [details]
replacement patch
the previous patch would mark the locked IU as a root if it was not already a root. However this lead the user to believe the install/update was going to happen. In this patch, the wizard reports an error (that the IU is already installed and cannot be updated).
Simon, can you give this a try?
Created attachment 129276 [details]
tweak of replacement patch
Thanks Susan.
This patch has a tiny tweak swapping the IU already installed for the upgrade IU when we're looking at in the profile for the lock property. This works for me now.
of course. thanks, Simon. Fixed in HEAD >20090318. *** Bug 266044 has been marked as a duplicate of this bug. *** Were the test units upgraded for this problem? |