Community
Participate
Working Groups
Build Identifier: M20090917-0800 It seems that when running as root, eclipse writes things in the installation directory that it ought to be writing in the user's "home" directory (in this case /root). The result in my case was that when I upgraded from fedora 11 to fedora 12, eclipse no longer worked. The problem was solved by uninstalling eclipse, then removing the files from /usr/share/eclipse and /usr/lib64/eclipse, and then reinstalling. I gather that running as root would cause similar problems for other users trying to use the same installation directory, though I have not tried this. Reproducible: Always Steps to Reproduce: (I have not actually done this more than once.) 1. install eclipse on fedora 11 2. run eclipse as root 3. upgrade to fedora 12
What Don would like is some way for the launcher to know that it's running as uid 0 and write to /root instead of the installation directory. Of course, this may break existing clients so perhaps it should be a switch (-Drootwritestoinstallation or something less verbose).
In general running user apps as root is a bad idea... That said, Andrew why don't you use a wrapper script for users to run Eclipse, which points the configuration into their home directory? http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/multi_user_installs.html The installer can by default make the whole install read-only: chmod -R -w /path/to/eclipse-install There shouldn't be any reason for an eclipse runtime to write to the central install location, so why not make it readonly?
I've tried to steer clear of wrapper scripts as they can lead to ugly bugs but if more users run into the situation that Don did it may be the best option. Thanks for the suggestion.
I think this may have been assigned to the wrong component. I figure someone will fix it if I'm wrong :)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.