Community
Participate
Working Groups
We have a scenario where feature A is dependent on feature B. If you install both A and B, and then uninstall feature B, the entry for feature B is not removed from the Installed Software list in Software Updates... 1) Install the Full SDK, and launch it. 2) Open the Software Updates UI, and install features A and B. I've been doing it from an archive. Restart Eclipse. 3) Open the Software Updates UI, select feature B, select the Uninstall button. Restart Eclipse. 4) Open the Software Updates UI, view the list of Install Software. Feature B is still displayed in the list. I've tried this on 2 different milestone builds, the latest being the M20081113-1232.
That's expected as far as what software is installed. e.g. B is removed as a root but A still needs B so we don't uninstall it. In terms of the state we track this would put you in the exact state as if you just installed A. It sounds like you've found a bug where we're either not clearing the ROOT property on the IU or else caching it in the UI model as B should not appear in the installed software list.
This sounds like a bug in the planner to me. I would expect the planner to return an error status indicating that B can't be uninstalled. The wizard shouldn't let you continue. I wouldn't want the UI to "pretend" to have uninstalled B and clear the root property, thus removing it from the list. If we can't uninstall B, we should say so. (Note - we do play the reverse trick during install when the user tries to install B and it's already there via a dependency in A. We mark it as a root so that B appears in the installed list even though it was there all along. But I don't like it - it's really a workaround for the fact that we didn't indicate to the user before-hand that it was already installed). Chris, is there a specific scenario you can describe to demonstrate the problem? (ie, the site and the features in question).
A scenario using Eclipse components would be: 1. Install the SDK. 2. Install Graphical Editing Framework GEF, restart Eclipse. 3. Install J2EE and Web Development Tools, restart Eclipse. 4. Uninstall GEF, restart Eclipse. 5. View the Install Software, GEF is still in the list.
Pascal, I can look at this from the UI side if needed. I'm surprised that the wizard let the user continue, but it may be a situation where the plan contained operands, but they had nothing to do with the original request???? Is this a case where the "actual change request" would notify the UI of the problem?
Susan, I looked at the core side of this problem and what we get is expected. If the profile change request emitted only contains a request to remove the IU, because the IU is not actually the removed the random properties attached to the IU are not removed (one of those being the ROOT property). If instead the profile change request says "remove the IU" and "remove the ROOT property" the property is removed accordingly. I'm not sure if the engine can do more at this stage without having an explicit knowledge of this root property. As for the idea of an Actual Change Request, there will be a way for the caller to know that the thing being requested for removal is not actually removed, however this will still not resolve the problem of removing the property. Unless of course the UI knows about this property and re-emit a change request. I released a test called Bug255984 showing the expected behavior.
The easy fix for the UI would be to always ask for the removal of the ROOT property all the time.
(In reply to comment #6) > The easy fix for the UI would be to always ask for the removal of the ROOT > property all the time. > I disagree with removing the root property as a fix until we have a way to tell the user that the uninstall won't happen. Otherwise we are "pretending" that the item has been uninstalled. A related note - now we are showing much more to the user about what is installed, they can drill down the profile roots and see what is there. So even if we were to remove the root, the user would see that it was still there. I think the correct fix here is to tell the user "B can't be uninstalled because A requires it." That is why I think the "Actual Change Request" support (or some workaround like it in the UI) is needed to truly fix the problem. As a side-effect of this, maybe the UI would remove the root property (so that the drill down in the installed view is reflective of why the item is there). I agree that property removal should be the UI's responsibility, I'm just not sure it is the right thing to do. Does the root property affect whether something would be uninstalled later? For example, if A requires B and both are roots, and A is uninstalled, will B remain because it is a root? Would it get uninstalled in the course of uninstalling A if it were not a root? These questions will help determine what the UI should do with the property. If B will always remain (whether it's a root or not) when A is uninstalled, then B needs to remain a root so that the user has the ability to uninstall it later when removing A or after removing A. If removing the root will allow it to go away when A goes away, then we could consider removing the property and telling the user something like... "B cannot be uninstalled because A requires it. B will be marked for uninstall but will remain until A is removed" or something like that. As for how we are handling this now - when you debugged this, did the provisioning plan have any operands? Was the status OK? The UI has code to catch the case where there are no operands and tell the user that nothing will happen, so I'm trying to understand why it proceeded at all.
Chris, Pascal and I discussed this topic, and it actually involves some pretty meaty issues. It might help to familiarize yourself with the user personas we're trying to use to make these discussions more concrete... http://wiki.eclipse.org/Equinox_p2_UI_Use_Cases In R3.4 we really tried to make the update UI friendlier for users like Ellen, perhaps at the expense of users like Laurel who understood Update Manager. So in your scenario: - In R3.4 the bug could likely be fixed as Pascal suggests. We could remove the "root" property from GEF so that it would disappear from the installed list, even though we didn't really uninstall anything. Makes Ellen (and Pascal) happy, but you (and Laurel, and me) feel like the system is lying. It's consistent but squirrely, in my opinion, although I think that any fix we backported to 3.4.x would do just this for consistency. - So what now in R3.5? We are trying to walk some middle ground that makes Laurel and Ellen both happy. We show drilldown in the wizards and the install list so that Laurel can see what is going on. We assume Ellen doesn't care and hope that the plus signs don't confuse her. Back to your scenario. The user wants to uninstall GEF. We need to tell them at some level that we can't do it. My proposal is that we open the wizard as if to uninstall GEF, with an information status message that says something like... Some parts of "GEF" are required by "Web Development Tools". The parts that are not required will be uninstalled. In the simplest of cases, the "part" of GEF that is uninstalled is simply the property that marks it visible in the install list. But there could legitimately be cases where certain features or bundles in GEF could be uninstalled, but not all of it (depending on how the requirements are expressed). The idea is that GEF can now be uninstalled when GMF is uninstalled, so your intention to get rid of it has been recorded and we do the best we can. From a persona point of view: - Laurel likely understands the message, appreciates the info. She might wonder what "parts of GEF" could actually be uninstalled, but otherwise kind of gets it. - Ellen might be confused by the message but honestly probably never would get into this scenario. - Steve probably wouldn't understand the message but would continue since the status is informational. A warning or error might cause him pause. - Dave would hope that his users would never be in this scenario, but understands the info. What do you think? (There is some related discussion concerning "install" going on in bug 216032 comment 12).
> So in your scenario: > - In R3.4 the bug could likely be fixed as Pascal suggests. We could remove > the "root" property from GEF so that it would disappear from the installed > list, even though we didn't really uninstall anything. Makes Ellen (and > Pascal) happy, but you (and Laurel, and me) feel like the system is lying. They're right. :) > My proposal is that we open the wizard as if to uninstall GEF, with an > information status message that says something like... > > Some parts of "GEF" are required by "Web Development Tools". The parts that > are not required will be uninstalled. > > In the simplest of cases, the "part" of GEF that is uninstalled is simply the > property that marks it visible in the install list. But there could > legitimately be cases where certain features or bundles in GEF could be > uninstalled, but not all of it (depending on how the requirements are > expressed). > > The idea is that GEF can now be uninstalled when GMF is uninstalled, so your > intention to get rid of it has been recorded and we do the best we can. Eh... :) I really dislike the idea of allowing actual state to be orthogonal to user's perception of state. User's view should always be consistent reflection of actual install state. But I'm not sure if that is what you are saying. In addition to above to cover this case.. Next Page (optional) for each dependency. "GMF includes GEF. You can.." "Keep GEF . (recommended)" "Remove unneeded GEF parts." "Remove Webtools, Zest, ..." (Next page..?) "GMF includes ABC. You can.." "Remove SuperABC, ..." Now, what happens when Webtools requires other pieces..arghh! My inclination would be to simply let the user know what is happening with a minimal top level of intervention. But this nesting business is just too tricky. I find the installation information hierarchy very confusing. We are really trying to describe an acyclic (hopefully!) graph with a hierarchy. I have this problem in an entirely unrelated piece of software and I'm finally just about ready to give up on a hierarchical representation. People just can't deal with having nodes appearing in multiple places. Maybe you need to throw up a Zest graph. :) Possibly.. simply do a full dependency tree search and then.. "GMF shares parts with other software." "Keep shared parts (recommended)." "Delete WebTools as well" "Delete SuperABC as well" "GEF is used by other software. To delete GEF you will need to delete these parts as well." "Do nothing." "Also delete WebTools and SuperABC." Perhaps there is a method to get detail on exactly what requires what. IIRC this is a bit like the original UI. What made older UI so *&( frustrating is that it seemed that no matter what you did you got these error boxes and couldn't accomplish anything. Users need sensible options that compress decision making as much as possible.
> Eh... :) I really dislike the idea of allowing actual state to be orthogonal to > user's perception of state. User's view should always be consistent reflection > of actual install state. But I'm not sure if that is what you are saying. I think that in 3.4 (without drilldown) we were indeed creating an orthogonal world, hence my focus on trying to fix it. However, I now see it as a "level of detail" issue, where we have to decide what is the least amount of detail to show? Because Eclipse is used in so many different product configurations and one product's major feature is another product's implementation detail (discussed ad nauseum in bug #224742), we start by saying that the simplest view of the world is the level of detail at which the user installed things. If I chose GEF, I care about GEF. If I didn't, I don't. I think this is a good place to start. The challenge is how to present more level of detail without completely overwhelming the person who doesn't want to see the detail. Can we satisfy both users or do we use policy to drive separate presentations? > But this nesting business is just too tricky. I find the installation > information hierarchy very confusing. We are really trying to describe an > acyclic (hopefully!) graph with a hierarchy. I have this problem in an entirely > unrelated piece of software and I'm finally just about ready to give up on a > hierarchical representation. People just can't deal with having nodes appearing > in multiple places. Maybe you need to throw up a Zest graph. :) I agree, the tree is used to try to straddle the fence so that Ellen doesn't see more detail than needed. If we decide that we've failed both Ellen and Laurel with this view, then a graph is an option for more advanced users. Of the options you propose I like this (synthesizing a few different ones and trying not to give too many choices) "GMF shares parts with WebTools and SuperABC" "Keep shared parts (recommended)." "Uninstall WebTools and SuperABC" This is what I was trying to describe in my proposal except that if we don't know which items depend on GMF, there's not really an alternate recommendation. It remains to be seen (bug #218055) whether I will have the info I need to make the more detailed alternate recommendation.
> Because Eclipse is used in so many different product configurations and > one product's major feature is another product's implementation detail > (discussed ad nauseum in bug #224742) Apologies, the bug reference should be bug 224472
OK, this is starting to make a bit more sense to me now. Its a bit like throwing Install History into the mix. As long as we're super explicit about that then I think that's OK. Actually an interesting exemplar is Mylyn which allows a user focused mode to be imposed. Mylyn would be a terrible way to implement this -- it has a wicked learning curve -- but perhaps could inspire way to think about this. Yeah, I think that the synthesized example is best as well. I think you might be able to do something similar with Install, which would address a bit of my long-winded discussion about product. Perhaps bug referenced above is talking about same issue. But got to back to my "real project" now. :)
*** Bug 260268 has been marked as a duplicate of this bug. ***
Created attachment 122275 [details] Installation information dialog post change I believe my problem is the same as this one. I delete the WST/XSD features listed as root features. I get an restart/apply now dialog (so it looks like it did something). But the features are still listed. If I drill down through the other features, I can't see them listed as requirements anywhere (which makes it not obvious why they weren't deleted). Trying a reset after the restart results in an NPE, bug 260728. PW
Fixed in HEAD >20090121. Given the current state of error reporting from the planner, I can only go so far in this area. There were some great ideas for quick fixes/user choices based on the failures, and I captured those in bug #261928. Reviewing the case that Chris reported: - install "Graphical Editing Framework GEF" - install "Web Development Tools" - go to "Installation Information", select "Graphical Editing Framework GEF", and press the Uninstall button Old behavior (BUG): uninstall wizard happily proceeds to do something (?) but GEF is not uninstalled and continues to appear in the Installed Software page. New behavior: uninstall wizard shows an INFO status that says: "Graphical Editing Framework GEF" cannot be fully uninstalled because other installed software requires it. The parts that are not required will be uninstalled. User can continue this wizard and in the end, GEF will no longer be visible at the root of the Installed Software page (although if you drill into "Web Development Tools" you would still see it.) As part of fixing this bug, I also included a similar message for the converse case. Suppose the user has Web Development Tools and sees GEF, and decides to install it. Today we just pretend to install it and set the visibility property. With this fix, we are a bit more honest. "Graphical Editing Framework GEF" is partially installed because other installed software requires it. The remainder will be installed. Bug #261928 covers being more specific about who requires what, etc...
