Bugzilla – Full Text Bug Listing
| Summary: | [planner] [ui] support for "deep" check for updates | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Susan McCourt <susan> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | david_williams, irbull, mistria, mmbossoni, mn, pascal, reckord, sbouchet, thomas |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 219122 | ||
| Bug Blocks: | |||
|
Description
Susan McCourt
I think one simple change could be to allow an already installed feature to be updated even if no newer version is found. The UI actually do allow such a feature to be checked for install and it is possible to click on the Next button. When you do however, you always get the message "No updates found". There are two reasons for fixing this. One is of course that it would enable the wanted updates. The other is that the current behavior is somewhat inconsistent. Why am I allowed to check a feature for install when it is known to fail in the next step? It's almost as someone did think that my scenario should be supported but then the backing functionality is missing. Or perhaps its not even missing anymore due the fix in bug 259537? *** Bug 322532 has been marked as a duplicate of this bug. *** Various discussions on EPP and better way to product packages are constrained and made more complex because p2 "Check for Updates" only checks for root, whereas it seems that the expected and simplest behavior, both from feature provider and user POV would be that "Check for Updates" updates whatever possible, be it root or transitive. (In reply to Mickael Istria from comment #3) > Various discussions on EPP and better way to product packages are > constrained and made more complex because p2 "Check for Updates" only checks > for root, whereas it seems that the expected and simplest behavior, both > from feature provider and user POV would be that "Check for Updates" updates > whatever possible, be it root or transitive. I think this should not be done automatically for all cases or all "products". The reason is that some adopters (and their users) depend on things remaining relatively constant so they can provide (and get) proper support -- over a period of several years. (That is, if each user/customer had their own particular mix of "updates", it would be nearly impossible to help them when they reported a bug.) (In reply to David Williams from comment #4) > I think this should not be done automatically for all cases or all > "products". > The reason is that some adopters (and their users) depend on things > remaining relatively constant so they can provide (and get) proper support > -- over a period of several years. (That is, if each user/customer had their > own particular mix of "updates", it would be nearly impossible to help them > when they reported a bug.) Ok. But don't version ranges and "includes" mechanics allow to constrain for stability without penalizing those who want new features and latest updates? Also, do adopters/users who want support use the "Check for updates" using non-supported sources such as SimRel? If you compare it to Linux distributuins, which are pretty good at updating themselves, it would mean that updates would only for example run for Gnome and never for GTK, that seems weird. Supported Linux versions actually support a sub-set of all available features, and packages them in a separated source that is the only one supported. All features coming from outside are not supported and mixing a supported installation with non-supported source is clearly not advised. IMO, it's not to the community to take responsibility, workload and constraints for commitments some adopters have made to their users. (In reply to Mickael Istria from comment #3) > Various discussions on EPP and better way to product packages are > constrained and made more complex because p2 "Check for Updates" only checks > for root, whereas it seems that the expected and simplest behavior, both > from feature provider and user POV would be that "Check for Updates" updates > whatever possible, be it root or transitive. For record and context, could you please describe here the problems encountered by the EPP packages? As for changing the default behaviour of p2 on search for updates, I think it needs to be something controlled by a switch (e.g. profile level property or system property), such that product producers can be the one having the final control over how they want to see things updated. (In reply to Pascal Rapicault from comment #6) > For record and context, could you please describe here the problems > encountered by the EPP packages? Context is the debate about whether having a single feature product vs having what product with multiple units as root units, and how it impacts ability to update products and then consider "major" version updates. Most is in this thread https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03943.html , with some interesting comparison with the Linux distributions that allow fluent and efficient updates and some concerns about whether p2 update could be too restricting to allow simple updates: https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03949.html > As for changing the default behaviour of p2 on search for updates, I think > it needs to be something controlled by a switch (e.g. profile level property > or system property), such that product producers can be the one having the > final control over how they want to see things updated. Yes, I agree that it seems better to have ability to control the update behavior. |