Bug 588517 - after upgrade from fc11 to fc12 eclipse missing lots of stuff needed to develop java
after upgrade from fc11 to fc12 eclipse missing lots of stuff needed to devel...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-03 16:54 EDT by Donald Cohen
Modified: 2010-05-07 15:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-07 14:12:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of command requested (182.19 KB, text/plain)
2010-05-06 12:55 EDT, Donald Cohen
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Eclipse Project 312108 None None None Never

  None (edit)
Description Donald Cohen 2010-05-03 16:54:00 EDT
Description of problem:
I upgraded from fc11 to fc12 and ran eclipse.
As an example of what's missing, window - show view - other contains, at the
top level, nothing starting with java.
It contains, in total:
general, cvs, debug, help, team, other


Version-Release number of selected component (if applicable):
about says
Version: 3.5.1
Build id: M20090917-0800

How reproducible:
I only upgraded once

Additional info:
I finally just downloaded eclipse from eclipse.org.
I unpacked it and out of the box the window - show view - other menu contains 19 items, inc. java, java browsing, javascript, javaserver faces.
Comment 1 Andrew Overholt 2010-05-03 17:02:23 EDT
Try moving ~/.eclipse out of the way:

mv ~/.eclipse{,.bug588517}

and re-start eclipse.  Try with a new workspace if you want to be safe (-data switch to the eclipse executable).

Note that Fedora doesn't include javascript or javaserver faces functionality so I assume you either installed those yourself in F-11 (can be re-done in F-12 as it's stored in ~/.eclipse) or are comparing the basic PDE Fedora package (eclipse-pde) with the full-blown EPP JEE package from eclipse.org.
Comment 2 Donald Cohen 2010-05-03 17:12:07 EDT
(In reply to comment #1)
> Try moving ~/.eclipse out of the way:
just did
 mv .eclipse/ .eclipse-fc11
and restarted -- same list of window views

> Note that Fedora doesn't include javascript or javaserver faces functionality
> so I assume you either installed those yourself in F-11 (can be re-done in F-12
> as it's stored in ~/.eclipse) or are comparing the basic PDE Fedora package
> (eclipse-pde) with the full-blown EPP JEE package from eclipse.org.    

True, I got the big one.  I didn't know which one corresponded to what I had
in fc11.  But I'm pretty sure that in fc11 I did have at least a java view.
What I see in yum list installed (same set for 12) is

eclipse-jdt.x86_64                      1:3.4.2-17.fc11                @updates 
eclipse-pde.x86_64                      1:3.4.2-17.fc11                @updates 
eclipse-platform.x86_64                 1:3.4.2-17.fc11                @updates 
eclipse-rcp.x86_64                      1:3.4.2-17.fc11                @updates 
eclipse-swt.x86_64                      1:3.4.2-17.fc11                @updates
Comment 3 Andrew Overholt 2010-05-03 17:18:43 EDT
There are some debugging commands on this page:

http://fedoraproject.org/wiki/DebuggingEclipseProblems

What output do they give?

eclipse-pde is the "top-level" RPM that matches what's in the "Eclipse Classic" or "Eclipse SDK" from eclipse.org.
Comment 4 Donald Cohen 2010-05-03 18:12:23 EDT
I see a lot of occurrences of "missing" below, which might have something to do with the issue at hand.

$ for f in `rpm -aq | egrep "eclipse|swt"`; do rpm -qV $f; done
..5....T.  c /usr/lib64/eclipse/configuration/config.ini
S.5....T.  c /usr/lib64/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
missing   c /usr/lib64/eclipse/configuration/org.eclipse.osgi/.bundledata.1
missing   c /usr/lib64/eclipse/configuration/org.eclipse.osgi/.lazy.1
missing   c /usr/lib64/eclipse/configuration/org.eclipse.osgi/.manager/.fileTable.4
missing   c /usr/lib64/eclipse/configuration/org.eclipse.osgi/.manager/.fileTable.5
missing   c /usr/lib64/eclipse/configuration/org.eclipse.osgi/.state.1
missing     /usr/lib64/eclipse/features/org.eclipse.rcp_3.5.1.R35x_v20090811-9sAiFxdFrfSVki-JAowu4M6e7BA6
missing     /usr/lib64/eclipse/features/org.eclipse.rcp_3.5.1.R35x_v20090811-9sAiFxdFrfSVki-JAowu4M6e7BA6/eclipse_update_120.jpg
missing     /usr/lib64/eclipse/features/org.eclipse.rcp_3.5.1.R35x_v20090811-9sAiFxdFrfSVki-JAowu4M6e7BA6/epl-v10.html
missing     /usr/lib64/eclipse/features/org.eclipse.rcp_3.5.1.R35x_v20090811-9sAiFxdFrfSVki-JAowu4M6e7BA6/feature.properties
missing     /usr/lib64/eclipse/features/org.eclipse.rcp_3.5.1.R35x_v20090811-9sAiFxdFrfSVki-JAowu4M6e7BA6/feature.xml
missing     /usr/lib64/eclipse/features/org.eclipse.rcp_3.5.1.R35x_v20090811-9sAiFxdFrfSVki-JAowu4M6e7BA6/license.html
S.5....T.    /usr/lib64/eclipse/artifacts.xml
.......T.  c /usr/lib64/eclipse/eclipse.ini
missing     /usr/lib64/eclipse/features/org.eclipse.cvs_1.1.101.R35x_v20090811-7E79FEd9KKF5H2UEPDBJ9L01A16
missing     /usr/lib64/eclipse/features/org.eclipse.cvs_1.1.101.R35x_v20090811-7E79FEd9KKF5H2UEPDBJ9L01A16/eclipse_update_120.jpg
missing     /usr/lib64/eclipse/features/org.eclipse.cvs_1.1.101.R35x_v20090811-7E79FEd9KKF5H2UEPDBJ9L01A16/epl-v10.html
missing     /usr/lib64/eclipse/features/org.eclipse.cvs_1.1.101.R35x_v20090811-7E79FEd9KKF5H2UEPDBJ9L01A16/feature.properties
missing     /usr/lib64/eclipse/features/org.eclipse.cvs_1.1.101.R35x_v20090811-7E79FEd9KKF5H2UEPDBJ9L01A16/feature.xml
missing     /usr/lib64/eclipse/features/org.eclipse.cvs_1.1.101.R35x_v20090811-7E79FEd9KKF5H2UEPDBJ9L01A16/license.html
missing     /usr/lib64/eclipse/features/org.eclipse.equinox.p2.user.ui_1.1.1.R35x_v20090811-7u6FbEFYXk1qWdbS0gnpRg2932
missing     /usr/lib64/eclipse/features/org.eclipse.equinox.p2.user.ui_1.1.1.R35x_v20090811-7u6FbEFYXk1qWdbS0gnpRg2932/eclipse_update_120.jpg
missing     /usr/lib64/eclipse/features/org.eclipse.equinox.p2.user.ui_1.1.1.R35x_v20090811-7u6FbEFYXk1qWdbS0gnpRg2932/epl-v10.html
missing     /usr/lib64/eclipse/features/org.eclipse.equinox.p2.user.ui_1.1.1.R35x_v20090811-7u6FbEFYXk1qWdbS0gnpRg2932/feature.properties
missing     /usr/lib64/eclipse/features/org.eclipse.equinox.p2.user.ui_1.1.1.R35x_v20090811-7u6FbEFYXk1qWdbS0gnpRg2932/feature.xml
missing     /usr/lib64/eclipse/features/org.eclipse.equinox.p2.user.ui_1.1.1.R35x_v20090811-7u6FbEFYXk1qWdbS0gnpRg2932/license.html
missing     /usr/lib64/eclipse/features/org.eclipse.help_1.1.1.R35x_v20090811-7e7eFAxFD3wTVSUkp6Uz0adF
missing     /usr/lib64/eclipse/features/org.eclipse.help_1.1.1.R35x_v20090811-7e7eFAxFD3wTVSUkp6Uz0adF/eclipse_update_120.jpg
missing     /usr/lib64/eclipse/features/org.eclipse.help_1.1.1.R35x_v20090811-7e7eFAxFD3wTVSUkp6Uz0adF/epl-v10.html
missing     /usr/lib64/eclipse/features/org.eclipse.help_1.1.1.R35x_v20090811-7e7eFAxFD3wTVSUkp6Uz0adF/feature.properties
missing     /usr/lib64/eclipse/features/org.eclipse.help_1.1.1.R35x_v20090811-7e7eFAxFD3wTVSUkp6Uz0adF/feature.xml
missing     /usr/lib64/eclipse/features/org.eclipse.help_1.1.1.R35x_v20090811-7e7eFAxFD3wTVSUkp6Uz0adF/license.html
missing     /usr/lib64/eclipse/features/org.eclipse.platform_3.5.1.R35x_v20090910-9pEeGFdFtnSu79iXcyV8_-gIogwPjafr5DGB7
missing     /usr/lib64/eclipse/features/org.eclipse.platform_3.5.1.R35x_v20090910-9pEeGFdFtnSu79iXcyV8_-gIogwPjafr5DGB7/eclipse_update_120.jpg
missing     /usr/lib64/eclipse/features/org.eclipse.platform_3.5.1.R35x_v20090910-9pEeGFdFtnSu79iXcyV8_-gIogwPjafr5DGB7/epl-v10.html
missing     /usr/lib64/eclipse/features/org.eclipse.platform_3.5.1.R35x_v20090910-9pEeGFdFtnSu79iXcyV8_-gIogwPjafr5DGB7/feature.properties
missing     /usr/lib64/eclipse/features/org.eclipse.platform_3.5.1.R35x_v20090910-9pEeGFdFtnSu79iXcyV8_-gIogwPjafr5DGB7/feature.xml
missing     /usr/lib64/eclipse/features/org.eclipse.platform_3.5.1.R35x_v20090910-9pEeGFdFtnSu79iXcyV8_-gIogwPjafr5DGB7/license.html

$ which java
/usr/bin/java

$ readlink -f `which java`
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java

$ which javac
/usr/bin/javac

$ readlink -f `which javac`
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/javac

$ java -version
java version "1.6.0_17"
OpenJDK Runtime Environment (IcedTea6 1.7.1) (fedora-37.b17.fc12-x86_64)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
Comment 5 Andrew Overholt 2010-05-04 08:14:09 EDT
(In reply to comment #4)
> I see a lot of occurrences of "missing" below, which might have something to do
> with the issue at hand.

Yup :)  I'd re-install the Eclipse RPMs (something like: rpm -e eclipse-{swt,rcp,platform,jdt,pde}; yum install eclipse-pde).

I honestly don't know how that happened.  Did something go wrong during the upgrade process?
Comment 6 Donald Cohen 2010-05-04 19:24:08 EDT
I don't see any evidence of problems during upgrade.
$ grep eclipse upgrade.log
Upgrading tomcat5-jasper-eclipse-5.5.27-7.4.fc12.noarch
Upgrading icu4j-eclipse-4.0.1-3.fc12.x86_64
Upgrading eclipse-swt-3.5.1-22.fc12.x86_64
Upgrading eclipse-rcp-3.5.1-22.fc12.x86_64
warning: /usr/lib64/eclipse/configuration/config.ini saved as /usr/lib64/eclipse/configuration/config.ini.rpmsave
warning: /usr/lib64/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info saved as /usr/lib64/eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info.rpmsave
Upgrading eclipse-platform-3.5.1-22.fc12.x86_64
warning: /usr/lib64/eclipse/eclipse.ini saved as /usr/lib64/eclipse/eclipse.ini.rpmsave
Upgrading eclipse-jdt-3.5.1-22.fc12.x86_64
Upgrading eclipse-pde-3.5.1-22.fc12.x86_64


Further, when I do the reinstall according to your directions above I end
up with the same result - top level items in the view menu are
 general, cvs, debug, help, team  (no other)
Comment 7 Andrew Overholt 2010-05-05 08:43:10 EDT
I'm using the same x86_64 F12 RPMs and can uninstall and re-install no problem.  Please remove the eclipse RPMs and then tell me what's left in /usr/lib64/eclipse and /usr/share/eclipse.  You can see if any other package owns the files with rpm -qf <file in question>.
Comment 8 Donald Cohen 2010-05-05 21:31:23 EDT
I guess by "remove the eclipse RPMs" you mean the same 
"rpm -e eclipse-{swt,rcp,platform,jdt,pde}" command as before?
$ ls /usr/lib64/eclipse
configuration  dropins	eclipse.ini.rpmsave  features  p2  plugins
$ ls /usr/share/eclipse
plugins

Is that what you meant?  What next?
Comment 9 Andrew Overholt 2010-05-06 09:35:37 EDT
Yes, I meant the same "rpm -e" as before.  Please do the following and attach the results to this bug:

  for f in `find /usr/lib64/eclipse /usr/share/eclipse`; do rpm -qf $f; done

Thanks.
Comment 10 Donald Cohen 2010-05-06 12:55:29 EDT
Created attachment 412114 [details]
output of command requested

I didn't expect it to be so long!
Comment 11 Andrew Overholt 2010-05-06 13:10:01 EDT
:)  It looks like either a yum or rpm transaction messed up somewhere or eclipse was run as root at some point.  I recommend (assuming eclipse* RPMs are not present):

  rpm -e icu4j-eclipse tomcat5-jasper-eclipse

That should leave all files in /usr/share/eclipse and /usr/lib64/eclipse owned by no packages.  Then, either delete everything in those directories or back it up if you want.  Finally:

  yum install eclipse-pde
Comment 12 Donald Cohen 2010-05-06 14:10:21 EDT
Is there some problems with running eclipse as root?
I do that.
Comment 13 Andrew Overholt 2010-05-06 15:23:53 EDT
(In reply to comment #12)
> Is there some problems with running eclipse as root?

Yes, it overwrites RPM-owned files and problems ensue like you've experienced here :)

I *highly* recommend against running it as root (and really most apps shouldn't ever be run as root) if you want your RPM installations of it to keep working.
Comment 14 Donald Cohen 2010-05-06 19:53:14 EDT
Well, that worked.  
I wonder what else doesn't work cause I ran it as root.
And how to find out.
This still feels like a bug to me.
I guess you're saying that running eclipse causes attempts to overwrite
files that would fail if not running as root?  And these failures are
caught and do not cause eclipse to crash?  Why are these attempts then not
bugs?
Furthermore, why should that cause a problem in upgrading?
You have to be root in order to do the upgrade so the upgrade process could
certainly delete files that belong to root.
Comment 15 Andrew Overholt 2010-05-07 11:15:20 EDT
Eclipse doesn't have a notion of different user ids.  One could argue that it _should_ on POSIX systems but good luck getting that one upstream :)

It blindly tries to write to its "installation" directory (not ~) which in the RPM case is /usr/lib{,64}/eclipse.  If it can't, it falls back to writing to ~/.eclipse.  The problems occur because the files in /usr/lib{,64} are owned and managed by RPM.  RPM can't manage files that it doesn't know about and Eclipse has written stuff there that affects runtime and then an RPM upgrade goes and overwrites _other_ files without Eclipse knowing and the combination of these files gives the behaviour you experienced.

One potential solution to this is a wrapper script for the launcher binary but I'm not a big fan of wrapper scripts as they tend to disguise real bugs and lead to others.
Comment 16 Donald Cohen 2010-05-07 12:50:34 EDT
You seem to be saying that the code expects to run in a machine where there is no ~, but if the first attempt to write fails then it tries ~ as a backup plan.
Simply reversing these two would seem to solve the problem.
Given that my problem was solved by (re)moving the installation directories,
I suggest that the upgrade process do the same thing.
Comment 17 Andrew Overholt 2010-05-07 13:44:41 EDT
(In reply to comment #16)
> You seem to be saying that the code expects to run in a machine where there is
> no ~

No, the code expects to run in a standalone, writable-by-the-user-that's-running-it directory.

> Given that my problem was solved by (re)moving the installation directories,
> I suggest that the upgrade process do the same thing.    

That's a bad thing to do because RPM should only be touching files that it has installed.

This is really NOTABUG or at least not in the sense of anything Fedora can do.  There's perhaps a deeper issue here but that belongs upstream.  If you file one at bugs.eclipse.org, please CC me.
Comment 18 Donald Cohen 2010-05-07 13:58:09 EDT
Isn't /root a standalone writable by root directory?
That's the place to write files like .eclipse when run by root.
Isn't rpm the one that installed /usr/lib64/eclipse and /usr/share/eclipse?
Comment 19 Andrew Overholt 2010-05-07 14:12:53 EDT
(In reply to comment #18)
> Isn't /root a standalone writable by root directory?

Sure.  But it's not the eclipse "installation directory".

> That's the place to write files like .eclipse when run by root.

Don't think I don't kind of agree but this is an upstream issue and should be taken there.

> Isn't rpm the one that installed /usr/lib64/eclipse and /usr/share/eclipse?    

Sure but it didn't necessarily write all the files that are in those directories when it comes time to upgrade.
Comment 20 Donald Cohen 2010-05-07 14:41:09 EDT
Ok, I've created an account at bugs.eclipse.org and filed Bug 312108
Thanks for your help.
Comment 21 Andrew Overholt 2010-05-07 14:45:06 EDT
Thanks.  I'm not sure where I came up with "Don" in my comment at bugs.eclipse.org but I can correct it if you'd like :)
Comment 22 Andrew Overholt 2010-05-07 14:46:14 EDT
... and of course I say that without realizing you used "Don Cohen" as your name there.  Too many bugs today ... ignore me :)
Comment 23 Donald Cohen 2010-05-07 15:03:27 EDT
I'm a little confused.  I see a couple messages at eclipse.org and then we move back to redhat.com.  It sounds like the suggestion of the installation process making the installation files read only might work.  On the other hand, so would changing eclipse to try to write in ~ first.
I begin to think that the real mismatch is that eclipse is intended not to be shared among users, i.e., that on a unix system every user is intended to install it on his own.  That's effectively what I did when I got the rpm from eclipse and installed it on /tmp.  It does seem like a waste of space for multiple unix users of the same eclipse version on the same machine but perhaps that's not the usual case anyway.  I don't suppose rpm supports user installation of packages in their home directories?

Note You need to log in before you can comment on or make changes to this bug.