Community
Participate
Working Groups
In bug #218055, the planner provides a RequestStatus that will make it clear if an uninstall or install request is not going to happen for a particular IU, but it can't really say why. The UI now uses this to inform the user when things they want to happen aren't really happening. Once we have explanation support (bug #200380), the request status should be able to provide more descriptive info about why a particular IU will not be uninstalled or installed. This would open the door for possible quick fixes and other improvements in the error reporting on the UI side. Best to explain with two common cases: Case #1 - User installs A. - User installs B, which requires A. - Now user tries to uninstall A. Today's user message in wizard: "A" cannot be fully uninstalled because other installed software requires it. The parts that are not required will be uninstalled. Underneath: The profile root property is removed but A remains. If user were to uninstall B, then A would be uninstalled. Future: With explanation support, we should be able to be more specific. "A" cannot be fully uninstalled because "B" requires it. What do you want to do? - uninstall the parts of A that can be removed - uninstall B and A Case #2 - User has B, which requires A. So A is installed, but user is not really aware of it. - User sees A in the available list, decides to install it Today's user message in wizard: "A" is partially installed because other installed software requires it. The remainder will be installed. Future: "A" is partially installed because "B" requires it. The remainder will be installed.
marking 3.5, but it's unclear how far we'll get in the blocking bug and how much time we'll have to improve this. This is an area where we could really improve the user experience. Other notes: - quick fixes require a "re-resolution" in the wizard, need to ensure the code paths can deal with that. That we aren't hanging onto old profile change requests, etc. - would be nice to have some helper methods in ProfileChangeRequest to alter the request (or create a new one) based on alterations. I had some experiments in this area, doing it from the client side, and it required some really ugly code on the outside to know about all the internal map structure of the ProfileChangeRequest and rebuild a new change request. This could help with the first issue, too, if we could just modify the existing request. Other UI possibilities if we have RequestStatus explanations: - show an error icon by any IU's where the request is to be ignored. - clicking on any IU shows the errors associated with only that IU and suggests possible fixes I couldn't do this today, because the RequestStatus reports too much in the absence of explanations. Example: User installs A, B, and C. The install can't happen because C requires D, which is not found. Today: ProvisioningPlan is in ERROR and reports "C requires D." However, the RequestStatuses for A, B, and C are all in error. So using the RequestStatus to build specific error markers marks too much. With explanation support, I would hope to see this: ProvisioningPlan is in ERROR and reports "C requires D." RequestStatus only shows error for C along with "C requires D" as explanation I could use this info to mark C in error and give user option to install only A and B.
Another scenario (see bug #252638). If we refuse to install a patch because it doesn't apply to the configuration, we currently say: "P" is not applicable to the current configuration and will not be installed. whereas we could instead say "P" is only applicable when "Z" is installed. What do you want to do? - ignore "P" - install "P" and "Z"
Pascal and I were discussing that some of the explanations may be cheaper to compute than others, so that the resolution result may have some explanations, but require further calls to get more detail. Here's a scenario we can use for discussion: Suppose user wishes to install A, B, C. Suppose that A is in conflict with the current profile, such that it cannot be installed without uninstalling X. Suppose that B and C are in conflict with each other, because they require different versions of Y. From a UI workflow point of view: - knowing that A cannot be installed in the current platform is more important than knowing the conflict between B and C. This is because I can immediately tell the user that A can't be installed and see if they prefer to try with only B and C. - knowing that A cannot be installed without uninstalling X is also useful because I could offer the user to first uninstall X. In either case, the user will probably alter the request (either remove A from consideration or cancel and proceed to uninstall X.) Only after conflicts with the profile are resolved do we care about conflicts between the things the user is trying to install. Pascal also mentioned that if B and C are in conflict because of different versions of Y, (and Y is a singleton), that it is "cheap" to report the conflict in Y, and more expensive/advanced to report who requires what. From a UI point of view, the cheap answer isn't very helpful, and we would likely always want to know who requires what, so that we can then let the user know that they could proceed by either dropping B or dropping C.
[cut and pasting my comment from bug 266760] Just one comment: I have been discussing explanation issues with Jed during the past hour. Shouldn't we propose a way to fix the problem? If we have a missing req, it means that a new update site needs to be added. Maybe a message say "Please add an update site providing <missing IU>." could be a nice advice to the user? If there is a singleton violation, the proposal is not obvious, I admit :)
(In reply to comment #4) > [cut and pasting my comment from bug 266760] > > Just one comment: I have been discussing explanation issues with Jed during the > past hour. > > Shouldn't we propose a way to fix the problem? > > If we have a missing req, it means that a new update site needs to be added. > Maybe a message say "Please add an update site providing <missing IU>." could > be a nice advice to the user? Absolutely. (Side note: We'll look to see whether the "Contact all sites" checkbox is checked. If it is not, we will advise them to try that. That is covered in bug 267464). > > If there is a singleton violation, the proposal is not obvious, I admit :) > See the last couple of paragraphs of comment #3. I haven't yet looked at the new explanation support to see how specific the singleton explanation is, but if we know what is requiring the different versions, then we have several proposals.
marking M7 now that we have explanation support
To properly mark selected items with errors, there is some refactoring we have to do in the wizard. I discussed this with Pascal a week or two ago, but never wrote it down, so I'm doing so now. In the wizards today, the basic flow is page 1 - select what you are doing page 2 - see the results (errors or else the drill-down resolution results with detailed requirements and sizes) page 3 - licenses, etc... For install we open on page 1. For uninstall and update we open on page 2 (because often the user has already selected what to work with). The problem with this is that today we show resolve errors on page 2 (a page that won't let you fix the selections.) In the long run we need to start showing resolution errors on page 1. This would allow us to mark items with error or warning indicators, or even offer to deselect a problem item. When the user clicks "Next" on this page, we resolve, and they only move to the next page if everything is ok. Then they see all the detail about the install. But if everything is not ok, they shouldn't move to the next page. This has bothered me for some time, but the reason I hadn't done it yet is that the page 1 in the install case is already way too cluttered. However I think the proposal for that problem is insert another page. So the workflow would be something like this: Uninstall - user selects items in installed software page and presses "uninstall." - if the uninstall resolves successfully, open wizard to page 2 (as we do today) - if the uninstall did not resolve, open the wizard to page 1 so they can change selections. Install - user selects "Install New Software..." - page 1 shows all the software. User can select what they want, press next (as today) - if it resolves successfully, move to the details page (as today) - if it does not resolve successfully, move to a page that shows only those things selected from the first page and shows the error markers, etc. (In other words, insert a SelectableIUsPage that looks like the simplified ones in the uninstall and update case.) Update - user selects Check for Updates (or selects specific items in the installed software page and selects "update") - if the update resolves successfully, open wizard to page 2 (as today) - open to page 1 if errors and let them change selections Another related issue that came up in bug 260625, is that in larger systems, when the user chooses "check for updates" or has automatic update turned on, we may want to open the wizard on page 1 rather than resolve everything up front and open on page 2. When many updates are proposed, the user may not want all of them. (However if the user has "download automatically" selected, we would still likely try to resolve with everything first.)
The refactoring discussed in comment #7 is now complete. Committed to HEAD >20090406. This doesn't introduce any improved error markers, but it moves us to the right direction by having errors reported on the page that lets you change the selections. Note that to get true error/warning markers on the items themselves, we'll need to have the UI generate RequestStatus objects that can be reported in the same way as the planner's objects. For example, we'd want to treat UI-generated warnings, such as "ignoring your request to install X because it is already installed" the same way as the planner generated ones.
Several weeks ago Pascal and I discussed that we were probably "good enough" with explanations for 3.5. The refactoring I did in comment #7 was important to me for 3.5 because we have introduced many workflow changes in 3.5, and I didn't want to come out of the gate in 3.6 with another big wizard workflow change to support explanations. Now that the movement through the wizard is set up for explanations/quick fix error reporting, we can focus on polishing this story in 3.6.
Here is an idea to improve the feedback to the user when a request fails. It would be nice to have a visual marker for the two possible failure problem: - a missing dependency (what about a "?") - conflicting versions (no idea here) Once the explanation is available, the message dialog only displays the cause of the problem, with the specific marker and : - the name of the IU to install and the missing package name - the name of the IU(s) to install and the conflicting package The full explanation shown right now would only be visible after pushing a details button. Following the previous comments, a possible fix could be proposed at the same time: - contact more repositories for missing IUs - do not install problematic IU - choose between problematic IUs the one to not install
*** Bug 306626 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > [cut and pasting my comment from bug 266760] > > Just one comment: I have been discussing explanation issues with Jed during the > past hour. > > Shouldn't we propose a way to fix the problem? > > If we have a missing req, it means that a new update site needs to be added. > Maybe a message say "Please add an update site providing <missing IU>." could > be a nice advice to the user? > > If there is a singleton violation, the proposal is not obvious, I admit :) Per bug 310206, we now detect a missing requirement and will enable the provisioning context to follow repository references. So if the site containing the IU refers to the site containing <missing IU>, and it's enabled, this will now "just work". I also wanted to point to the code I used to detect this, for future reference. Unfortunately I now have to reach into internals to make this happen. InstallOperation. missingRequirement(IProvisioningPlan failedPlan)
*** Bug 311279 has been marked as a duplicate of this bug. ***
note for future: I'd like to see the UM install handler case considered as "Just another resolution problem" when we address this bug. See bug 310667. We should have a way for someone outside of the operation to hook into resolution and append statuses. See also bug 241683.
Pascal and I have been working on this (although I don't know if this is the right bug report). Pascal wrote a resolution operation that 'relaxes' constraints. This is helpful when we hit the conflicting version problem. I added a button in the wizard to allow users to resolve with these relaxed constraints. The idea is that if they fail, they can try this button (kinda like I'm feeling lucky). There are still a few things left to do: 1. Only show the button if the first resolution actually fails 2. Make this button (the showing of it) configurable in the policy 3. Show errors that this resolution produces (if this fails, we don't show the error) Also, I think the resolution needs some improvement. Currently it seems to try and update all IUs, not just relax the constraints. I'm committing the first version of this so we can test it a bit.
Ian, is this visible in the UI by default? I just tried a scenario which I thought would show it, but nothing happened. (project setup as described in Bug 348124 comment 4)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
