Bugzilla – Full Text Bug Listing
| Summary: | Unsatisfied update descriptor still allows update | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | DJ Houghton <dj.houghton> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, irbull, john.arthorne, pascal, pwebster |
| Version: | 3.8.0 Juno | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | stalebug | ||
|
Description
DJ Houghton
(In reply to comment #0) > > ... this is actually a bug in p2, > the second update action shouldn't be allowed to proceed. > Why is this a bug? Because the "update descriptor" should still apply? Or something else? (In reply to comment #1) > Why is this a bug? Because the "update descriptor" should still apply? Or > something else? Correct. The IU says that it is an update for a range, but we are allowing the update to continue even though the range doesn't match. To be more specific, it can't be an update because the range isn't satisfied and it can't be a new IU added to the install because the org.eclipse.sdk.ide IU is a singleton and only one version can be installed at a time. (In reply to comment #3) > ... > and it can't be a new IU added to the install because the org.eclipse.sdk.ide > IU is a singleton and only one version can be installed at a time. I'm probably being dense here, but I do not understand ... you can certainly install new singletons ... and the new one "takes effect" on restart ... that happens all the time. And ... as long as org.eclipse.sdk.ide is "top level", that is, nothing else depends on it; nothing else constrains it to a lower level, then seems to me like it is not a bug to be able to install it. Unless you are saying the intent is that "install" follows the same rules established by update descriptors? (which would not be related to a bundle being a singleton ... so, I'm obviously missing something). The bug being referred to here is one in the UI. Let me try to explain. In the case where I have SDK 3.8 installed and SDK 4.2 (as described in comment#0) in a repo, check for updates will not say that 4.2 is an update of 3.8. This is expected and good since this is the behaviour we are looking for. Now if the user explicitly picks 4.2 in the install dialog and proceeds, the wizard will say "hey, I notice that you already have SDK installed. I changed your request to be an update from 3.8 to 4.2". This update detection logic is what I believe is incorrect since the update descriptors are not being taken into account to propose the update. The point of opening the bug is to acknowledge this bug (well at least I managed to convince ppl it was a bug earlier today :) ), record the fact that if it gets fixed then we will make it harder for ppl to update from 3.8 to 4.2 and thus that we may need to enhance the p2 metadata to be able to handle this more gracefully. HTH (In reply to comment #5) > The bug being referred to here is one in the UI. Let me try to explain. > In the case where I have SDK 3.8 installed and SDK 4.2 (as described in > comment#0) in a repo, check for updates will not say that 4.2 is an update of > 3.8. This is expected and good since this is the behaviour we are looking for. > Now if the user explicitly picks 4.2 in the install dialog and proceeds, the > wizard will say "hey, I notice that you already have SDK installed. I changed > your request to be an update from 3.8 to 4.2". This update detection logic is > what I believe is incorrect ... Now I understand. (well, as best I ever could :) ... thanks! I've been thinking about this and I'm still not convinced it's a bug. I always thought of the update descriptor as an extra piece of metadata to help us find updates for non-obvious cases. For example if a feature is renamed, split, or merged, an updated descriptor can be used to still offer updates. But there's a difference between using it to *find* updates, versus using it to disallow an update that the end user explicitly selected. Having a mechanism to completely disallow particular updates might have some uses, but in the end the user can always break it apart into "Uninstall A1", followed by "Install A2", for all cases except the root platform case, so it doesn't seem all that valuable. If we fixed this problem, at what level would it be done? Would the update descriptor be encoded into the resolver problem, or would it be enforced in the engine? 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. This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. |