Bug 332158

Comment 1 Daniel Le Berre 2010-12-29 13:45:05 EST

The problem found by the resolver is that you cannot have both JDT core 3.6.1.v_A68_R36x (from the 3.6.1 distro) and 3.6.1.xx-20101124-2100-e36 (a requirement of Groovy) installed together.

Comment 2 Andrew Eisenberg 2010-12-29 13:56:43 EST

(In reply to comment #1)
> The problem found by the resolver is that you cannot have both JDT core
> 3.6.1.v_A68_R36x (from the 3.6.1 distro) and 3.6.1.xx-20101124-2100-e36 (a
> requirement of Groovy) installed together.

Right, that's what the error message says, but if you remove step #2 above, then the install works fine.

Comment 3 Andrew Eisenberg 2010-12-29 14:23:52 EST

My hunch is that because the install directory is read-only, p2 has no way of uninstalling the original jdt.core file.  Therefore, there is a conflict when trying to install the patched version.

However, I have no evidence to back this up.

Comment 4 Daniel Le Berre 2010-12-29 15:08:38 EST

(In reply to comment #3)
> My hunch is that because the install directory is read-only, p2 has no way of
> uninstalling the original jdt.core file.  Therefore, there is a conflict when
> trying to install the patched version.

You are probably right.

The error message comes from the resolver, that does not have any other information available.

I am not sure where the read-only shared install property could be checked.

Maybe as a warning in the update manager GUI (a bit like capslock when you enter a password)?

Comment 5 Andrew Eisenberg 2010-12-29 15:24:31 EST

(In reply to comment #4)
> Maybe as a warning in the update manager GUI (a bit like capslock when you
> enter a password)?

This might be reasonable, but my understanding is that non-patch features can be properly installed in a read-only situation.  In the common case, then the warning would be superfluous.

Comment 6 Daniel Le Berre 2010-12-29 16:05:41 EST

can someone confirm that this is the expected behavior?

It looks strange that such problem only arises for patch feature.

Comment 7 Pascal Rapicault 2011-01-11 22:53:15 EST

Short answer: what you see is expected / explainable.
Long answer: This behaviour results from the fact that the install is "shared" (aka read only). In this case, p2 assumes that nothing from the "base" (the part being marked read-only) can change. 
This is implemented by a having a fake IU that requires every IU from the base thus locking them to be what they are. Consequently, in your use case, the patch can not be installed because the JDT feature is locked and the patch does not know about the existence of this fake IU to apply the patch to it as well, so it creates a conflict.

Comment 8 Andrew Eisenberg 2011-01-11 23:25:14 EST

Thanks for clarifying why we are seeing this message.  But, with this in mind is there some way to make the failure message a little clearer?

For example, p2 knows to create this fake IU when in a shared install instance.  Also, p2 knows that a feature patch exists (because <property name='org.eclipse.equinox.p2.type.patch' value='true'/> is in the content.xml).  So, given these two properties and a conflicting dependency failure, could you add a more descriptive error message, something like;

"Perhaps your install directory is read-only.  Feature patches cannot be installed into read-only directories."

If this message is produced when not in a shared install mode, it's not a big problem, but it can be a big help if the message comes out in the right circumstances.

Comment 9 Andrew Eisenberg 2011-04-05 15:43:01 EDT

Any chance that something could happen for this bug for 3.7?  There are still many of my users who are hitting it.

Comment 10 Andrew Eisenberg 2011-10-13 18:56:16 EDT

I am working on a patch to fix this bug.  Here is a sketch of what I am doing.

In the ResolutionResult.appendDetailText() method, look for patterns that indicate that an install is failing because of a Shared Install. Essentially, just look for the text "Software currently installed: Shared profile".  There may be a better way of doing this, but I'm just not sure what it would be.

If this pattern is found, then add the following text to the summary:

    Attempt to install into a read-only (shared) location.
    Ensure that the current user has write access to install location and try again.

(I'm happy to work on the wording, but at least that is the gist of what I would like it to say.)

So, the full error message would become something like this:

Cannot complete the install because of a conflicting dependency.
  Software being installed: Groovy-Eclipse Feature 2.6.0.xx-20111012-2100-e37 (org.codehaus.groovy.eclipse.feature.feature.group 2.6.0.xx-20111012-2100-e37)
  Software currently installed: Shared profile 1.0.0.1318531229691 (SharedProfile_SDKProfile 1.0.0.1318531229691)
    Attempt to install into a read-only (shared) location.
    Ensure that the current user has write access to install location and try again.
  Only one of the following can be installed at once: 
    Java Development Tools Core 3.7.0.v_B61 (org.eclipse.jdt.core 3.7.0.v_B61)
    Java Development Tools Core 3.7.1.xx-20111012-2100-e37 (org.eclipse.jdt.core 3.7.1.xx-20111012-2100-e37)
  Cannot satisfy dependency:
    From: Shared profile 1.0.0.1318531229691 (SharedProfile_SDKProfile 1.0.0.1318531229691)
    To: org.eclipse.jdt.core [3.7.0.v_B61]
  Cannot satisfy dependency:
    From: Shared profile 1.0.0.1318531229691 (SharedProfile_SDKProfile 1.0.0.1318531229691)
    To: org.eclipse.jdt.feature.group [3.7.0.v20110520-0800-7z8gFchFMTdFYKuLqBLqRja9B15B]
  Cannot satisfy dependency:
    From: Groovy-Eclipse Feature 2.6.0.xx-20111012-2100-e37 (org.codehaus.groovy.eclipse.feature.feature.group 2.6.0.xx-20111012-2100-e37)
    To: org.codehaus.groovy.jdt.patch.feature.group [2.6.0.xx-20111012-2100-e37]
  Cannot satisfy dependency:
    From Patch: org.codehaus.groovy.jdt.patch.feature.group 2.6.0.xx-20111012-2100-e37 Eclipse Java Development Tools 3.7.0.v20110520-0800-7z8gFchFMTdFYKuLqBLqRja9B15B (org.eclipse.jdt.feature.group 3.7.0.v20110520-0800-7z8gFchFMTdFYKuLqBLqRja9B15B)
    To: org.eclipse.jdt.core [3.7.1.xx-20111012-2100-e37]


If this kind of strategy seems reasonable, I will get a patch together for this and submit it.

Comment 11 Andrew Eisenberg 2011-12-22 15:51:22 EST

Is it possible that this bug has been made superfluous?

I just tried to install a feature patch into a read-only Eclipse 4.2M4 and the installation worked with no problems.  When I try the same thing on 3.7.1, I get the error described below.

Does anyone know of any work done in this area that would allow feature patches to be installed into Shared Profiles?  If so, this is great news since this means that a better error message is not needed any more since this scenario now works.

Comment 12 Roberto Sanchez Herrera 2012-11-09 13:15:35 EST

Any possible answer to the last question from Andrew? Andrew, did you find the answer elsewhere? I'm seeing a similar problem in Eclipse Helios

Comment 13 Andrew Eisenberg 2012-11-09 13:24:38 EST

No I have not found an answer.  Have you tried on Juno?  As I said, I found this was working on Juno, but not Helios.

Comment 14 Roberto Sanchez Herrera 2012-11-09 13:35:40 EST

Yes, I tried Indigo SR2 and Juno SR1 Java EE packages, and the problem is fixed there. But I'm working on Helios, and I'd like to track down where this was fixed.

Comment 15 Pascal Rapicault 2012-11-13 20:23:38 EST

This is interesting because as far as I can tell this was still an issue in 3.8.1 (be it plain SDK or one of the EPP package). Are you positive that this now works? Are you sure that the content being patched is not installed through dropins?

Comment 16 Roberto Sanchez Herrera 2013-01-11 15:18:23 EST

(In reply to comment #15)
> This is interesting because as far as I can tell this was still an issue in
> 3.8.1 (be it plain SDK or one of the EPP package). Are you positive that
> this now works? Are you sure that the content being patched is not installed
> through dropins?

I just tested this again using Indigo, Juno and Helios EPP, and I only see this problem in Helios. 

I suspect the problem was fixed as part of bug 350380, so I'm investigating that bug.

Comment 17 Stephan Herrmann 2013-01-24 17:37:36 EST

Bug 281510 has similar stories, it has a vote (not mine :) ) and is blocking another bug.

Here's the latest from Bug 281510 comment 23:

> In 4.2 this bug seems to be back to where we started 3 years ago:
> 
> Install a Juno package as root. As a user without write permission to the
> install, install any patch feature.
> 
> Effect:
> - no error message (neither dialog nor log), install proceeds as normal
> - the patch feature is "installed" but its plug-in is NOT
> - any subsequent install of any software is effectless
> 
> According to comment 22 the cryptic error message (see comment 13) left
> users completely at loss. The current state with no error message is even
> worse.
> 
> At least we need good error messages, please.

Comment 18 Pascal Rapicault 2013-04-03 10:45:24 EDT

Hamdan, could you please see where we stand on this issue with the most recent I build from Kepler.

Comment 19 Pascal Rapicault 2014-05-05 10:22:01 EDT

Will not be addressed in Luna.