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.
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.
(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
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.
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)
(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?
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)
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>.
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?
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.
Created attachment 412114 [details] output of command requested I didn't expect it to be so long!
:) 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
Is there some problems with running eclipse as root? I do that.
(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.
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.
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.
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.
(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.
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?
(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.
Ok, I've created an account at bugs.eclipse.org and filed Bug 312108 Thanks for your help.
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 :)
... and of course I say that without realizing you used "Don Cohen" as your name there. Too many bugs today ... ignore me :)
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?