Hi,
* Dan Thurman <dant@xxxxxxxxx> [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
Attachment:
pgpPMXwfMjyX8.pgp
Description: PGP signature
-- fedora-devel-java-list mailing list fedora-devel-java-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
