Bugzilla – Full Text Bug Listing
| Summary: | P2 UI should not allow me to select stuff that cannot be installed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Miles Daffin <miles.daffin> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cvgaviao, irbull, jamesblackburn+eclipse, jeffmcaffer, matthew, remy.suen, thomas | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Miles Daffin
Some things like platform filters could be detected and filtered. However, the general solution would require us to run the planner for each IU before displaying it. For something like helios this would probably take 10 minutes. Then I think that anything that can be filtered out inexpensively should be. You have to draw the line somewhere. +1. It would make a lot of sense to hide everything that can be filtered out without involving the planner. That should include platform filters and all features that are solely for target platform provisioning (easy to recognize since they have a requirement for the namespace 'A.PDE.Target.Platform'). We already filter based on platform filters. We added a checkbox saying: "Show only software applicable to target environment". (In reply to comment #4) > We already filter based on platform filters. We added a checkbox saying: > "Show only software applicable to target environment". That begs the question, when would it ever be interesting to see tings that are not applicable? The "software" will be rejected anyway if an attempt is made to install it. My preference would be to remove that option and always apply the filter. at least in the target provisioning case it is interesting to see things for different platforms. Whether that needs to be exposed in the "normal" ui is a different question. I agree with Thomas but would go further. In the context of the installation use case it is disadvantageous to show stuff that cannot be installed. If people need to be able to see *all* the stuff in a repo then this is a different use case, and there are other tools available for this (e.g. the B3 Aggregator, which allows you to browse everything in a repo: Categories, features, bundles, products, fragments etc. etc.). (In reply to comment #6) > at least in the target provisioning case it is interesting to see things for > different platforms. Agree. But that's a very different use-case specific to PDE developers. No reason for it to clobber the general p2 installer. After all, it has its own set of options like "Include required software" and "Include source if available". Surprisingly, it doesn't have the one about the "Show only software applicable to target environment". What's the rationale behind that? Perhaps we ought to change the show only applicable software to default enabled? (In reply to comment #9) > Perhaps we ought to change the show only applicable software to default > enabled? Perhaps we should also change the caption to "Show only software that can be installed" in order to make it very clear to the user that by enabling this, he will see things that aren't just inapplicable, they can in fact not be installed at all. Then again, if they cannot be installed, why show them in the installer? (In reply to comment #8) sure. I just wanted to remind people that various parts of the p2 UI are reused in other scenarios (as per its design) so you need to be aware of these other usecases when change the base behaviour. > Surprisingly, it doesn't have the one about the "Show only software > applicable to target environment". What's the rationale behind that? The default is to populate the target with only the things applicable to the target environment (the option you mention). You can say you want to "Include all environments" but only if you are running the slicer (unchecked "Include required software"). (In reply to comment #10) > Perhaps we should also change the caption to "Show only software that can be > installed" that statement would be true if we ran the planner and confirmed that all things shown could actaully be installed (see comment #1). Otherwise the user will say "show me only stuff that can be installed" and then may get an error saying something could not be installed because of some missing requirement. The wording has to set expectations. (In reply to comment #11) > that statement would be true if we ran the planner and confirmed that all > things shown could actaully be installed (see comment #1). OK, sure. So the caption should be "Show software that definitely cannot be installed" and have it disabled by default. The conclusion is the same. It's a rather odd option to have in an installer. (In reply to comment #5) > That begs the question, when would it ever be interesting to see tings that are > not applicable? The "software" will be rejected anyway if an attempt is made to > install it. My preference would be to remove that option and always apply the > filter. This proposal would make it impossible for users to install software when the requirements don't match exactly. It's very important that users be able to debug _why_ a feature can't be installed. A case in point is your example in comment 0. Presumably you wanted to install the valgrind tooling. p2 told you why it couldn't install it and you can take that message to mailing list for help on how to get the feature installed... As a non-expert p2 user I need all the help I can get when trying to install features from non-aggregate update sites. The eclipse release train update site is a special case where most things are self consistent -- trying to install from anywhere else is often more painful. So -1 for silently hiding features with no way to discover why the feature can't be installed. (In reply to comment #13) > This proposal would make it impossible for users to install software when the > requirements don't match exactly. No, it would not. It is already impossible. > It's very important that users be able to debug _why_ a feature can't be installed. Yes, I agree, but only when this concerns features that are meant to be installed into the users environment. Displaying software that was never intended to be installed can serve no other purpose than confuse the user. > As a non-expert p2 user I need all the help I can get when trying to install > features from non-aggregate update sites. Exactly. So for starters, you'd probably like to filter out stuff that isn't intended for your environment. (In reply to comment #14) Ok, another example. The IBM ClearCase native plugins have a platform filter for x86 which means they can't be installed on x86_64. There're no native bits in the plugins, and IBM Rational WON'T FIX the issue. (I've filed a PMR, and there's been a community RFE, all of which were closed as the feature is in maintenance mode.) They actually recommend that customers tweak the feature.xml file themselves: https://www-304.ibm.com/support/docview.wss?uid=swg21460547 Now clearly this is broken, but as a user wanting to install the feature I wouldn't have found out what the problem was if the feature was hidden with no way to see it. (In reply to comment #15) > Now clearly this is broken, but as a user wanting to install the feature I > wouldn't have found out what the problem was if the feature was hidden with no > way to see it. Assuming the user knew about the feature the problem would reveal itself immediately. The feature is missing. To make it an issue you must say that the user is unaware of the existence of the feature that he has a desire to install. The objective for the installer is to install software. It's not a generic p2 repository browser aimed to support people with an desire to coerce features. As Miles points out in comment #7, there are other tools available for that. If the check-box for "Show things not applicable to your environment" stays, then it should be disabled by default and the things displayed only because it's enabled should be grayed out or somehow marked as uninstallable. That would support your use-case in an acceptable way. My preference though, is still to remove it completely. (In reply to comment #16) > Assuming the user knew about the feature the problem would reveal itself > immediately. The feature is missing. But how do I know what caused it? Which feature.xml should I look at? Which line causes the problem? Knowing which constraint failed is key to debugging installation failures. People ship update sites as zips and other people try to install features from them. If it doesn't work, silence is not a good fallback. Users will report, "It wouldn't install" and there'll be nothing we can do to help them. > If the check-box for "Show things not applicable to your environment" stays, > then it should be disabled by default and the things displayed only because > it's enabled should be grayed out or somehow marked as uninstallable. That > would support your use-case in an acceptable way. That sounds fine. I'm just keen that eclipse doesn't throw away information that will help users achieve their end-goal: installing the feature. (In reply to comment #17) > People ship update sites as zips and other people try to install features from > them. If it doesn't work, silence is not a good fallback. Users will report, > "It wouldn't install" and there'll be nothing we can do to help them. > My concern is to avoid just that. I don't want the user to even try. I prefer a "I can't find it" countered with "What platform are you on?". Problem solved. (In reply to comment #17) > But how do I know what caused it? Which feature.xml should I look at? Which > line causes the problem? Knowing which constraint failed is key to debugging > installation failures. > I do sense a misunderstanding here, or perhaps not. But just to clarify; I'm not suggesting that any feature with a problem should be hidden. I'm merely suggesting that features that are clearly not suitable should be hidden. That includes features with filters that discriminates them from the get go. Features that cannot be installed because the planner is unable to resolve a plan for other causes will still be visible. The installer doesn't know about that until an attempt is made to install. I see the ambiguity in my original statement now, so it is my fault. "I find it a bit absurd that the P2 UI allows me to browse and select for install stuff that, for one reason or another, cannot actually be installed." There are 3 main reasons why something cannot be installed: 1. There are missing dependencies 2. There is a conflict 3. The thing in question is not for the target platform 1 and 2 can only be determined when the planner has done its work, and I did not mean either of these. I meant sense 3. For example, I should *not* be able to select a Linux specific IU for installation on a windows platform. It makes no sense in this context. I hope this is clearer. (In reply to comment #20) > I meant sense 3. For example, I should *not* be able > to select a Linux specific IU for installation on a windows platform. It makes > no sense in this context. I hope this is clearer. Well the UI should make it clear you can't install it (and possible hide it by default if you want). But the checkbox to 'show incompatible features' should exist so users can find out *why* they can't install the feature from the update site they've unzipped. It really is important that there's enough information for users to work out why something isn't working. Users should be able to figure out why it doesn't work for themselves without needing to understand p2 or ping the feature's mailing list. Fundamentally p2 is an install manager, and a good install manager should tell me when it can't do something as well as when it can do something. A simple message when selecting an incompatible feature: "X is not compatible with Linux x86_64" or "X requires Y which isn't compatible with ..." would be sufficient. (In reply to comment #21) > Well the UI should make it clear you can't install it (and possible hide it by > default if you want). But the checkbox to 'show incompatible features' should > exist so users can find out *why* they can't install the feature from the > update site they've unzipped. While I agree in principle, the workflow where the user knows what is in the repo by a means other than the p2 UI is somewhat advanced. Most users don't get and unzip repos, they point at something that someone else has placed and they may or may not be able to browse on disk. So if things are hidden in the p2 UI then they won't even know what they are "missing" and the "why" question will not come up. Adding more ui options for every possible way of looking at the data does not IMHO make p2 more usable. Sure if it addresses a common problem but otherwise, we should just hide things that are not applicable (applicability filter does not pass for the destination profile) and call it a day. Created attachment 192759 [details]
Change default UI Policy to filter on environment
I've attached a patch to default on if there aren't objection.
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. |