Red Hat Bugzilla – Bug 89742
New gcj java stuff interferes with common java packaging
Last modified: 2007-04-18 12:53:20 EDT
The jpackage project was founded by redhat and mandrake users that worked with
java but didn't find their favorite apps and libraries in rpm form.
It has evolved in a rather big rpm java repository, and is currently moving from
its first major version
(ftp://us.dl.sf.net/pub/sourceforge/jpackage/direct_download/1.0) to the next
The big change between 1.0 and 1.5 is support for multiple parallel jvm
installations since java apps can be very sensitive to the actual jvm used and
different users had very different requirements.To support this the project
makes extensive use of alternative (also useful to provide choice between
full-fledged non-free implementations and partial free software reimplementations).
Starting with RedHat 9 we've started receiving lots of strange bug reports. It
turns out Red Hat now installs by default gcj binaries in the place where
alternative tries to put its link, and thus breaks jvm installation.
We'd very much like not to have put gcj conflicts in our specs since it would
mean lots of users would ignore gcj altogether and we very much hope gcj will
succeed. We'd rather have gcj use the same alternative targets as our other jvms
so people could install free and non-free stuff in parallel, try gcj and switch
to it as soon as it's complete enough for them.
The spec files used by the project are available at
in the JPACKAGE_UTILS_1_5 branch or in src.rpm/nosrc.rpm form at
All the jvms are in sync and work together (except sun 1.4.2 beta which is still
a WiP ATM)
linux+java is a vary nice platform and we hope everyone will continue to work
together to streghten it
The JPackage devel list can be reached at JPackagefirstname.lastname@example.org
mail archives are available at
Right now the lone conflict with having libgcj installed and java-1.4.1-sun from
JPackage is /usr/bin/jar which gets silently overwritten by update-alternatives
-- I don't know if alternatives should throw an error if the symlink location is
an existing file instead of another symlink.
Created attachment 101266 [details]
patch to resolve libgcj JPackage conflicts
This is how I'm proposing we fix the problem. Does it look like the right
I assume this needs to be updated following the latest discussion on
Created attachment 101374 [details]
second attempt at a patch to resolve libgcj JPackage conflicts
Here's the updated patch.
Created attachment 101375 [details]
Here's the script that is run if the user tries to run java or javac.
An errata has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.