Bugzilla – Full Text Bug Listing
| Summary: | [shared] Can't install Subclipse on 3.6RC3 due to conflicting dependency | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Andre Costa <blueser> | ||||||||
| Component: | p2 | Assignee: | Simon Kaegi <simon_kaegi> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | david_williams, irbull, jacek.pospychala, john.arthorne, kim.moir, Olivier_Thomann, overholt, pascal, pwebster, tjwatson | ||||||||
| Version: | 3.6 | Flags: | tjwatson:
pmc_approved+
irbull: review+ pascal: review+ |
||||||||
| Target Milestone: | 3.6 RC4 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
I just confirmed: if ownership of install dir is changed to the user that runs Eclipse then Subclipse installs just fine. Moving to Equinox/P2 Simon, could you please take a look. I just tried with a shared install Eclipse RC4 and Subclipse from: http://subclipse.tigris.org/update_1.6.x I had no problems at all. -- Andre can you give more detail on what you were using. I see references to EPP so could you give us the exact name and version of what you were installing from. Thanks. Hi Simon,
I just tried again. This is my setup here:
~ ls -l /usr/local
total 52
drwxr-xr-x. 2 root root 4096 Oct 1 2009 bin
lrwxrwxrwx. 1 root root 24 Jun 4 19:34 eclipse -> eclipse-3.6-RC3/eclipse/
drwxr-xr-x. 3 costa costa 4096 May 26 00:54 eclipse-3.5.2
drwxr-xr-x. 3 costa costa 4096 May 29 11:18 eclipse-3.6-RC2
drwxr-xr-x. 3 root root 4096 Jun 6 23:01 eclipse-3.6-RC3
~ ls -l /usr/local/eclipse-3.6-RC3/
total 4
drwxrwsr-x. 9 root root 4096 Jun 3 07:10 eclipse
I run eclipse through this script:
#!/bin/bash
pushd /usr/local/eclipse > /dev/null
./eclipse -vmargs \
-Xms256m -Xmx1024m \
-XX:PermSize=128m -XX:MaxPermSize=256m \
-XX:+UseConcMarkSweepGC \
-Djava.library.path=/usr/lib64/ \
"$@" > /tmp/eclipse.out 2>&1
The result when I tried to install Subclipse was the same as before: conflicting dependency (see screenshots).
I installed using eclipse-java-helios-RC3-linux-gtk-x86_64.tar.gz which I downloaded from Developer Builds page. Please let me know exactly what info you need and I'll provide it here.
Created attachment 171226 [details]
initial installation screen
Created attachment 171227 [details]
installation failure screenshot
Thanks Andre, I can reproduce this easily. It's a problem with an IU name conflict between the shared profile IU and the epp package IU. -- Guys I think we need to do something for RC4 here. The problem is that the IU we use for capturing the shared profiles requirements is named based on the profile name. For EPP packages the profile name they use is the same as their top level IU. We can fix this by making the shared profile IU name something like "shared_" + profileName instead of just profileName. Created attachment 171296 [details]
proposed patch
This is what I'm thinking of. I tested this out and it prevents the problem.
Again I really think we should consider this as all shared install of the EPP Packages will now work at the moment and the fix is low risk.
I discussed this with Simon. The fix could theoretically be released into 3.6.1. But the issue is very severe for linux installations that use EPPs. I think this is likely to be very common in the linux community. Another possibility is to ask the EPPs to change their profile name or their top level IU. Since we don't really have any guidelines for this there is nothing that will prevent others from doing the same. I also don't know how easy it is for all EPPs to change at this point. The best coarse of action likely is to go with this one line code change. I had the following questions when discussing this with Simon. 1) This fix only affects shared installs. Yes 2) Where is this ID used. The ID is really only used to keep us honest. If the shared install is updated it will get re-created. It does not prevent updates from previous builds (and theoretically from 3.5.x). The shared profile ID is totally synthetic. 3) Are there issues with removing the old IU No we're ok for removing it. (I don't know the details on this one, perhaps Simon can fill in the details). I'm totally in favour of this fix. We can discuss it during this afternoon call. Hi Simon, (In reply to comment #8) > Thanks Andre, > I can reproduce this easily. It's a problem with an IU name conflict between > the shared profile IU and the epp package IU. Nice, I'm glad you could reproduce it =) > Guys I think we need to do something for RC4 here. > > The problem is that the IU we use for capturing the shared profiles > requirements is named based on the profile name. For EPP packages the profile > name they use is the same as their top level IU. > > We can fix this by making the shared profile IU name something like "shared_" + > profileName instead of just profileName. My $0.02: yes, please make it high priority and provide a fix for this problem before 3.6 final, don't let it slip to 3.6.1, otherwise it will prevent us from doing shared installs when Helios comes out. The fact that we're unable to do shared installs right now due to bug #287246 already forces us to instruct people to install their own copies of Eclipse on their homes, instead of having a central shared (local) installation. This leads to wasted disk space and worse performance (since eclipse can't run from local disk and must run from NFS partitions). I am counting on Helios to allow us to do shared installs ;-) I agree this bug is major and a fix should be included in 3.6.0. We need two additional committers on p2 to review. Just out of curiosity (I'm not doubting the importance) is this a regression? Or just a late discovered conflict? (In reply to comment #14) > Just out of curiosity (I'm not doubting the importance) is this a regression? > Or just a late discovered conflict? This is a regression. In 3.5 p2 did not generate this synthetic ID for shared installations. Now that it does there is a chance for a collision. Kim, please be aware that we will be needing a post RC4 build for this bug. (In reply to comment #14) Also, it was discovered late because the problem does not occur with Eclipse platform or Eclipse SDK shared installs. The problem only came up because of a coincidence in how EPP are naming their profiles (profile id matching the product id). It does appear though that nobody tested installing anything in a EPP shared install until June 4th (our RC4 date). In case anyone was interested, none of the Linux distribution packages of Eclipse stuff that I know of use EPP as a base so this won't affect them if it isn't present with a base SDK or Platform. (In reply to comment #17) > In case anyone was interested, none of the Linux distribution packages of > Eclipse stuff that I know of use EPP as a base so this won't affect them if it > isn't present with a base SDK or Platform. By curiosity do you know why that is? I can verify that there is a problem (I cannot install into a shared install from an EPP package), and when I apply this patch the problem no longer appears. The fix also looks safe, except if we are searching for that ID somewhere else. (Simon mentioned on the call today that this is not the case). Just a note: I first created a shared install and tried to install Git and it failed. I then applied the fix to my shared area and it still failed. I had to "re-install" eclipse with the patch applied. This is likely because the shared profile was already created and replacing the bundle after-the-fact did nothing. Patch released in HEAD. Thx for the quick turn around Simon. . (In reply to comment #18) > (In reply to comment #17) > > In case anyone was interested, none of the Linux distribution packages of > > Eclipse stuff that I know of use EPP as a base so this won't affect them if it > > isn't present with a base SDK or Platform. > By curiosity do you know why that is? Because it's easier to do aggregation at the Linux package (RPM, deb) level in ways expected by distribution users than to build a big package like one based on an EPP release. Also, it's ver (In reply to comment #22) > (In reply to comment #18) > > (In reply to comment #17) > > > In case anyone was interested, none of the Linux distribution packages of > > > Eclipse stuff that I know of use EPP as a base so this won't affect them if it > > > isn't present with a base SDK or Platform. > > By curiosity do you know why that is? > > Because it's easier to do aggregation at the Linux package (RPM, deb) level in > ways expected by distribution users than to build a big package like one based > on an EPP release. Also, it's ver [continuing from above] y common for emphasis to be put on small, reusable packages that match their upstream components 1:1. I downloaded RC4 tarball yesterday and just tested it; the problem still exists:
Cannot complete the install because of a conflicting dependency.
Software currently installed: Shared profile 1.0.0.1276155449236 (epp.package.java 1.0.0.1276155449236)
Only one of the following can be installed at once:
Eclipse IDE for Java Developers 1.3.0.20100609-1425 (epp.package.java 1.3.0.20100609-1425)
Shared profile 1.0.0.1276155449236 (epp.package.java 1.0.0.1276155449236)
Cannot satisfy dependency:
From: Shared profile 1.0.0.1276155449236 (epp.package.java 1.0.0.1276155449236)
To: epp.package.java [1.3.0.20100609-1425]
Has the patch been applied on these RC4 tarballs yet? Should I have done anything different? (as before, I just extracted the tarball as root:root and tried to launch Eclipse as a regular user).
Hi Andre and thanks for re-testing. No it looks like the EPP Packages where using the Eclipse Platform from RC4. The relevant fix came in a "rebuild" post RC4 but still should be in the "release" verison of the EPP Packages. And ... Andre ... if you'd like to test an EPP package that has that fix, there are "nightly" builds of the EPP packages available at http://www.eclipse.org/epp/download.php (Just keep in mind, they are "nightlies", that is, no one has really looked at them, and while I'd expect them to be fairly solid, there's always a chance something was off with some particular nightly build). Thanks for your help. |
Build Identifier: 20100603-0907 Eclipse was unpacked as root on /usr/local/eclipse, and then ran as a regular user. When I try to install Subclipse, it fails with this error message: Cannot complete the install because of a conflicting dependency. Software currently installed: Shared profile 1.0.0.1275559853315 (epp.package.java 1.0.0.1275559853315) Software currently installed: Eclipse IDE for Java Developers 1.3.0.20100529-0859 (epp.package.java 1.3.0.20100529-0859) Only one of the following can be installed at once: Eclipse IDE for Java Developers 1.3.0.20100529-0859 (epp.package.java 1.3.0.20100529-0859) Shared profile 1.0.0.1275559853315 (epp.package.java 1.0.0.1275559853315) Reproducible: Always Steps to Reproduce: 1.unpack helios-RC3 tarball as root 2.run eclipse as regular user 3.try to install Subclipse from its official update site