Bugzilla – Full Text Bug Listing
| Summary: | Planner-based resolvers may choose different versions for different OS | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Tobias Oberlies <t-oberlies> | ||||
| Component: | Tycho | Assignee: | Project Inbox <tycho-inbox> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | minor | ||||||
| Priority: | P3 | CC: | contact | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 550601, 356582 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Created attachment 202594 [details]
Small project which doesn't reproduce the problem because it is too small
I compared the content from Indigo SR0 and Eclipse Project build M20110728-1200 more closely, and found the problem isn't as hard as I thought: The feature org.eclipse.platform.source, which is the one referenced with open version range, and most other units have correctly increasing version numbers. There are only four units [1] which have a lower version number in the newer build. (The analysis in the last paragraph of the description is wrong - the resolution for Linux was the optimal one, not the one for Windows.) This is quite annoying, because it shows that the planner doesn't reliably find the optimal solution for projects with a large dependency closure. I'll try to open a bug on p2 for this. [1] org.eclipse.equinox.p2.core.feature.source org.eclipse.equinox.p2.extras.feature.source org.eclipse.equinox.p2.rcp.feature.source org.eclipse.equinox.p2.user.ui.source Darn... when I try to strip down our internal project to only include Eclipse content (1300 units in the slice, ~1050 units in the resolution result), the problem doesn't occur. Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only. |
In a project with a large dependency closure (~1400 units in the slice, ~1100 units in the planner result), I have seen the case the the planner picks the newest version of a feature (for an unrestricted reference) for one platform, but an older version on a different platform. Due to the way that Tycho currently resolves for multi-platform builds (it takes the union of the resolution results per platform), the resolved project dependencies contain two versions of a feature, but only one version each of the OS-specific fragments included in the features. This is then detected by the mirroring step when creating an eclipse-repository. In the case that I have seen, the Linux resolution picked the old "a" version, resulting in the following message: [WARNING] Mirror tool: "Problems resolving provisioning plan.": ["Unable to satisfy dependency from org.eclipse.rcp.source.feature.group 3.7.0.v20110216-9DB5FmNFnFLSEetJz-mReHnt0255 to org.eclipse.swt.win32.win32.x86.source [3.7.1.v3736a]."] ... [WARNING] Mirror tool: "Problems resolving provisioning plan.": ["Unable to satisfy dependency from org.eclipse.rcp.source.feature.group 3.7.0.v20110216-9DB5FmNFnFLSEetJz-mReHnt0255 to org.eclipse.swt.win32.win32.x86_64.source [3.7.1.v3736a]."] ... [WARNING] Mirror tool: "Problems resolving provisioning plan.": ["Unable to satisfy dependency from org.eclipse.rcp.source.feature.group 3.7.0.v20110216-9DB5Fm1FpBGy_AaVz-mFamgY to org.eclipse.swt.gtk.linux.x86_64.source [3.7.0.v3735b]."] When trying to reproduce the problem in a smaller project, the planner chose the same version for both Windows and Linux - which means that the optimal solution contains the same version for both OS. In the large project however, the planner just doesn't seem to find the optimal solution when resolving for Linux. In fact, when I give the planner more time/iterations to look for the optimal solution [1], it does find the optimal solution even in the large project. The consequence of this bug is that an eclipse-repository contains two versions of a feature, but only one of them can be installed per platform. This is not a problem for a version range dependency to the duplicate feature - the planner will just pick the one that works - but when the users explicitly choose to install the duplicate feature in the latest version, it is a problem on some platforms. I think that this bug should only occur rarely. In our case, the planner was faced with a pretty hard problem: the newer feature had a lower version number ('1' < 'N'!), and only by looking at the content ('b' > 'a'), the planner could figure out which feature is the newer one and therefore preferable. I guess that we could live with sub-optimal resolution results in rare cases, but getting both versions in the resolved dependencies is at least unfortunate. I guess that we will need to teach p2 to do mult-platform planning in one go; this would solve this problem. [1] by setting -Declipse.p2.projector.timeout=x, with x significantly larger than the default 1000