| Summary: | [p2] weird behavior when trying to install conflicting patch feature | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Stephan Herrmann <stephan.herrmann> |
| Component: | p2 | Assignee: | Pascal Rapicault <pascal> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | marco, susan |
| Version: | 3.4.1 | ||
| Target Milestone: | 3.5 | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Stephan Herrmann
I assume Pascal will chime in on some of the patch-specific issues. I would be interested in reproducing the steps where there was a license page shown with no items in the list. Normally we prevent the license page from showing if there are no items with licenses (or if the license was one that was previously accepted). Also meant to say... Bug 249605 reports a similar problem where patches aren't showing up as installed. the fact that other updates/items were brought in along with the patch and not shown to the user is discussed at length in bug #224472 which is being investigated right now. (In reply to comment #2) > Also meant to say... > Bug 249605 reports a similar problem where patches aren't showing up as > installed. Well, not seeing the patch feature at one stage of the wizard was confusing, but I guess in this particular case p2 had already decided not to install the patch at all - afterwards there was no trace in about dialog nor in the file system. > the fact that other updates/items were brought in along with the patch and not > shown to the user is discussed at length in bug #224472 which is being > investigated right now. sorry to say: No, there was no dependency between the to-be-installed feature (not being installed in the end) and those updates that actually came in. And: doesn't the UI usually display all features it is going to install right after resolving the install request? I suggest to investigate what happens when one attempts to install two conflicting patches (i.e., independent patch features, patching the same installed feature). I guess the particular symptoms could just be caused by p2 being completely overwhelmed by such request. Does this guess make sense to you? (In reply to comment #1) > I would be interested in reproducing the steps where there was a license page > shown with no items in the list. Normally we prevent the license page from > showing if there are no items with licenses (or if the license was one that was > previously accepted). Actually, there WAS one item selected, but we were confused because a) if only one item is selected for install, the license page just shows the license text and no longer the corresponding features on the left side of the window b) in our case, the license text was empty ... Really surprising was the update process that started instead of the install without being asked to do so. >Upon finish, p2 did NOT install the requested feature >but UPDATED many installed features which it had not >reported on any of the previous wizard pages. >Well, not seeing the patch feature at one stage of the wizard was confusing, >but I guess in this particular case p2 had already decided not to install >the patch at all - afterwards there was no trace in about dialog nor in the >file system. I think the first step is to verify whether p2 indeed installed the patch or not. In bug #249605, we are seeing some unexpected provisioning operands generated when there is a request to upgrade a patch and the end result is that the patch is installed but there is no evidence in the installed software list. We need to make sure you were looking in the right places (the bundles.info and the .profile file would have references to the patch if it were installed.) >sorry to say: No, there was no dependency between the to-be-installed >feature (not being installed in the end) and those updates that actually >came in. And: doesn't the UI usually display all features it is going to >install right after resolving the install request? Unfortunately the UI currently doesn't show features that would be installed due to dependencies. That is the discussion in bug 224472 and now also in bug 250862. My best guess at the moment is that this some variant of bug 249605. I think that perhaps the patch was installed, and for some reason it brought in some other changes, either due to a bug in the planner or due to some dependencies that were not obvious and not shown in the UI. Assigning to Pascal for now since he will be looking into the possibly related bug. I should be more clear here: - if the patch you applied on the same feature had the same id as the original patch, such that installing the new patch was interpreted as an upgrade to the old patch, then my explanations in the previous comment might be true. - if the patch you applied to the same feature had a different id than the original patch, such that installing the new patch was installing an additional patch onto the same original feature, then my explanations aren't valid - this is a different problem. Either way I think Pascal is the best person to take this. Stephan, could you please give an example of the kinds of conflicts that you think about when you say: "I suggest to investigate what happens when one attempts to install two conflicting patches (i.e., independent patch features, patching the same installed feature). " I just want to make sure that I reproduce the proper problem. Thx. Pascal, in our case there were two independent patch features with different IDs (e.g. 'patch1' and 'patch2') targeting the same original feature (say 'base'). patch1 was already applied when we tried to install the second one, patch2. The result was that patch2 wasn't installed, but a lot of updates to other (unrelated?) features. One more thing to notice: the first patch was already installed in the distribution (RSA 7.5) while the second one we tried to install interactively with p2 Software Updates UI. Does this clarify? I believe this is a dupe of 254481. Closing as such for now. Please reopen if anything else shows up. *** This bug has been marked as a duplicate of bug 254481 *** |