Bug 89742

Summary: New gcj java stuff interferes with common java packaging
Product: [Retired] Red Hat Linux Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: jdkgcjAssignee: Jakub Jelinek <jakub>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: dgregor, fitzsim, rdieter, scop
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://www.jpackage.org/
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-03 01:30:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to resolve libgcj JPackage conflicts
none
second attempt at a patch to resolve libgcj JPackage conflicts
none
explanation script none

Description Nicolas Mailhot 2003-04-27 13:05:00 UTC 
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
one (ftp://us.dl.sf.net/pub/sourceforge/jpackage/direct_download/1.5)

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
http://www.zarb.org/horde/chora/cvs.php/rpms/?rt=jpackage 
in the JPACKAGE_UTILS_1_5 branch or in src.rpm/nosrc.rpm form at
ftp://us.dl.sf.net/pub/sourceforge/jpackage/direct_download/1.5
(for example
ftp://us.dl.sf.net/pub/sourceforge/jpackage/direct_download/1.5/generic/non-free/SRPMS/java-1.4.1-sun-1.4.1.02-68jpp.nosrc.rpm)

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 


Additional info:

The JPackage devel list can be reached at JPackage-discuss

mail archives are available at 

http://lists.zarb.org/mailman/listinfo/jpackage-discuss
Comment 1 Jason Corley 2003-04-27 13:55:48 UTC 
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.
Jason
Comment 2 Thomas Fitzsimmons 2004-06-19 20:45:42 UTC 
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
approach?
Comment 3 Nicolas Mailhot 2004-06-24 13:04:08 UTC 
I assume this needs to be updated following the latest discussion on
jpackage-discuss
Comment 4 Thomas Fitzsimmons 2004-06-24 14:33:28 UTC 
Created attachment 101374 [details]
second attempt at a patch to resolve libgcj JPackage conflicts

Here's the updated patch.
Comment 5 Thomas Fitzsimmons 2004-06-24 14:35:10 UTC 
Created attachment 101375 [details]
explanation script

Here's the script that is run if the user tries to run java or javac.
Comment 6 Jay Turner 2004-08-03 01:30:14 UTC 
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.

http://rhn.redhat.com/errata/RHBA-2004-385.html