|Summary:||New gcj java stuff interferes with common java packaging|
|Product:||[Retired] Red Hat Linux||Reporter:||Nicolas Mailhot <nicolas.mailhot>|
|Component:||jdkgcj||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||9||CC:||dgregor, fitzsim, rdieter, scop|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-08-03 01:30:14 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 JPackagefirstname.lastname@example.org 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