Re: What is going on with Eclipse, and PUP? [SOLVED, but other issues]

[Dan Thurman]

On Wednesday 30 January 2008 12:32:04 pm Andrew Overholt wrote:
>  Mark C. Allman wrote:
>  > Yea, a bug report can be filed, but the root question still is: do the
>  > Eclipse packages install a working app?  Does anyone have it working?
>
>  Of course.  I think Dan's on the road to fixing his issues.  He had lots
>  of RPMs that were missing files.  When he fixes that, I have no doubt
>  it'll work.
>  Andrew 
Yes, Andrew is right.  I have gotten my eclipse running now.

You can use the information in the following link to help debug your eclipse 
packages.  It should show you or the developer what might be broken with your 
eclipse installation.

http://fedoraproject.org/wiki/DebuggingEclipseProblems

We think that my main issue was centered around the issue of completely 
removing the eclipse package and trying to start over clean. I had 'yum 
remove eclipse*', then  deleted /usr/{lib,share}/eclipse not realizing that I 
had not removed the libswt3-gtk2.i386 package first.  Re-installting eclipse 
will not fix the problem. Having first removed libswt3-gtk2, icu4j-eclipse, 
eclipse-ecj, and tomcat5-jasper-eclipse and then (re)install eclipse fixed my 
problem.

Another point to make here is that if you should decide to use eclipse's 
software updater, you may encounter a situation for certain packages which 
are hardwired (by eclipse) wanting to be installed 
in /usr/{lib,share}/eclipse directory which will require root permissions and 
as a normal user, installation will completely fail. Most other packages 
allows a normal user to change the package's target directory.  I believe 
Andrew is saying that hardwired package target directory is a bug and all 
packages should be user-definable target directory.

Do not be tempted to change the permissions to allow the Software updater to 
install packages in /usr/{lib,share}/eclipse directories or in directories 
that do not have normal user permissions.

This is how I got into this mess in the first place.

The specific packages that I found wanting to be installed was: "Eclipse CVS 
Client", and "Java Development Tools"

Meanwhile, I am not sure what to do about installing the above two packages - 
that is another issue maybe Andrew can tell me at this point.  Hey Andrew? :D

Another thing, when I use the Eclipse Software Updater, I picked 'Europa 
Discovery', and selected everything except "Eclipse CVS Client" and
"Eclipse 
Java Development Tools", and unfortunately - there was a conflict.  The 
conflict is that the latest Eclipse Software version is v3.3.2 and even 
though I have changed my installation target directory, it still complains 
that in doing so, it will conflict with the same packages of v3.3.0 located 
in the /usr/{lib,share}/eclipse directories.

I am not sure what to do about this case either.  Andrew? :D

Well that's it for now.
Dan

What is going on with Eclipse, and PUP? [SOLVED, but other issues]

[Andrew Overholt]

Hi,

* Dan Thurman <dant(a)cdkkt.com&gt; [2008-01-30 19:11]:
>  Another point to make here is that if you should decide to use
> eclipse's 
>  software updater, you may encounter a situation for certain packages which 
>  are hardwired (by eclipse) wanting to be installed 
>  in /usr/{lib,share}/eclipse directory which will require root permissions and 
>  as a normal user, installation will completely fail. 
You can't *update* things installed as RPMs.  This is expected.  You
can, however, install new things.  I think you may running into the
issue that upstream's Update Site is providing versions of things that
are greater in version than the ones you have installed as RPMs.  Don't
blindly attempt to update and install all stuff from upstream's update
site unless you're using an upstream download.  (Yes, ideally we'd have
upstream releases as they were released by we don't in this case and my
3.3.1.1 update caused issues that I don't think were acceptable.)

>  Most other packages allows a normal user to change the package's
>  target directory.  I believe Andrew is saying that hardwired package
>  target directory is a bug and all packages should be user-definable
>  target directory. 
You shouldn't need to change the target directory.  If you're a regular
user, it'll just default to ~/.eclipse somewhere.

>  Do not be tempted to change the permissions to allow the Software
> updater to 
>  install packages in /usr/{lib,share}/eclipse directories or in directories 
>  that do not have normal user permissions. 
Indeed, the Update Manager will write things to the configuration
directory that don't allow regular users to start up the next time.

>  The specific packages that I found wanting to be installed was:
> "Eclipse CVS 
>  Client", and "Java Development Tools" 
I think you're looking for the eclipse-cvs-client and eclipse-jdt RPMs
:) .  The eclipse SRPM is the Eclipse SDK and is divided up by Eclipse
features (sets of plugins) into binary RPMs.

>  Another thing, when I use the Eclipse Software Updater, I picked
> 'Europa 
>  Discovery', and selected everything except "Eclipse CVS Client" and
> "Eclipse 
>  Java Development Tools", and unfortunately - there was a conflict.  The 
>  conflict is that the latest Eclipse Software version is v3.3.2 and even 
>  though I have changed my installation target directory, it still complains 
>  that in doing so, it will conflict with the same packages of v3.3.0 located 
>  in the /usr/{lib,share}/eclipse directories. 
See my comment above.

If non-SDK upstream packages (I'm speaking about things here like GMF,
BIRT, etc.) have dependencies on SDK bundles with versions greater than
what we have in the RPMs, then I guess we're out of luck.  How about
creating packages of these things for Fedora?  :)

After reading this rant-y sounding email one my ask "Why don't you just
fix the Update Manager to work for Fedora, Mr. Complain-y Pants?"  The
answer to that is that the whole provisioning infrastructure is being
re-written upstream and I'm working hard with them to ensure our "shared
install" (RPM) case works.  Thus, while there may be *some* issues today
(which I honestly haven't had any reports of people hitting -- other
than Dan :), I think the future will be much brighter :)

Andrew