Community
Participate
Working Groups
I am trying to update to the API Branch Build #31. When I simply do a check for updates, I get the following error: Cannot complete the install because of a conflicting dependency. Software being installed: Eclipse SDK 3.6.0.I20091217-0307 (org.eclipse.sdk.ide 3.6.0.I20091217-0307) Only one of the following can be installed at once: Dropin Reconciler Plug-in 1.0.100.v20090831 (org.eclipse.equinox.p2.reconciler.dropins 1.0.100.v20090831) Dropin Reconciler Plug-in 1.0.100.v20091010 (org.eclipse.equinox.p2.reconciler.dropins 1.0.100.v20091010) Dropin Reconciler Plug-in 1.0.100.R3_6_api_cleanup_v20091216 (org.eclipse.equinox.p2.reconciler.dropins 1.0.100.R3_6_api_cleanup_v20091216) Dropin Reconciler Plug-in 1.0.100.R3_6_api_cleanup_v20091210 (org.eclipse.equinox.p2.reconciler.dropins 1.0.100.R3_6_api_cleanup_v20091210) Dropin Reconciler Plug-in 1.0.100.v20090520-1905 (org.eclipse.equinox.p2.reconciler.dropins 1.0.100.v20090520-1905) Cannot satisfy dependency: From: Equinox p2 Provisioning 1.2.0.R3_6_api_cleanup_v20091202-8279FfoFPlS1R9yWhkRjgE2cByir (org.eclipse.equinox.p2.user.ui.feature.group 1.2.0.R3_6_api_cleanup_v20091202-8279FfoFPlS1R9yWhkRjgE2cByir) To: org.eclipse.equinox.p2.reconciler.dropins [1.0.100.R3_6_api_cleanup_v20091210] Cannot satisfy dependency: From: Eclipse SDK 3.6.0.I20091217-0307 (org.eclipse.sdk.ide 3.6.0.I20091217-0307) To: org.eclipse.equinox.p2.user.ui.feature.group [1.2.0.R3_6_api_cleanup_v20091202-8279FfoFPlS1R9yWhkRjgE2cByir] Cannot satisfy dependency: From: Eclipse SDK 3.6.0.I20091217-0307 (org.eclipse.sdk.ide 3.6.0.I20091217-0307) To: toolingorg.eclipse.sdk.ide.configuration [3.6.0.I20091217-0307] Cannot satisfy dependency: From: toolinggtk.linux.x86org.eclipse.equinox.p2.reconciler.dropins 3.6.0.I20091217-0307 To: bundle org.eclipse.equinox.p2.reconciler.dropins 1.0.100.R3_6_api_cleanup_v20091216 Cannot satisfy dependency: From: toolingorg.eclipse.sdk.ide.configuration 3.6.0.I20091217-0307 To: toolinggtk.linux.x86org.eclipse.equinox.p2.reconciler.dropins [3.6.0.I20091217-0307]
I have reproducible steps now: 1. Install Eclipse 3.6M4 2. Upgrade to branch build #28 3. Upgrade to branch build #31 #fail Of course, I'm running linux, so it could be a platform thing. Has anybody else tried the upgrade to #31?
While we were chatting you mentioned the strange name in the profile, does that also occurs during those steps?
I tried I20091209-1800 -> 28 -> 31 on linux.gtk.x86_64 and got the similar results. I didn't have problems before on windows, but I think I skipped 28 and was doing 26->31
Looking at the metadata, the IU org.eclipse.equinox.p2.user.ui.feature.group did not increase in version between 28 & 31, both are 1.2.0.R3_6_api_cleanup_v20091202-8279FfoFPlS1R9yWhkRjgE2cByir This is the source of the conflict, the update is keeping the old version which conflicts with the requiresments in the updated product. Normally this is caused by a small delta between the contents of the two features, which makes the change to the version suffix not significant enough to escape truncation. Here, nearly half the contained bundles did change, but I suspect the same thing happens due to the longer qualifiers we are using in the branch : 1.0.100.R3_6_api_cleanup_v20091208 instead of 1.0.100.v20091208 The longer "R3_6_api_cleanup_" prefix here makes the suffix delta that much further to the right in the final suffix string, and more likely to be lost in truncation. Options are: 1) ignore the problem, just retag our features for each build, things will be better after merge back to head 2) Ask Kim to change the default suffix length in the branch builder to account for the longer input versions.
Awesome Andrew, thanks for figuring this out. Is there a reason why we truncate at all? Pascal, no, the strange profile name did not happen in this case. I suspect I originally installed with the director and didn't specify a profile name (or specified it in a strange way -- maybe through a script or something).
(In reply to comment #5) > Awesome Andrew, thanks for figuring this out. Is there a reason why we truncate > at all? There are sometimes path-length issues on windows. The generated suffixes can get quite long, especially with nested features. There is some discussion over on bug 175714
*** This bug has been marked as a duplicate of bug 175714 ***