Hi,
Based on the discussions on this list as well as a phone discussion we just had, here are the plans for these scripts:
aot-compile-rpm ---------------
We're going to put the logic from this script upstream in the GCC repository. Gary is going to split it into a package-format agnostic "aot-compile" script and an RPM-specific fragment for gleaning settings from an RPM build environment.
This location for the "natively compile a set of jars" logic has two advantages: aot-compile can be conveniently reused by other packaging systems (e.g. Debian, Gentoo) and the logic can be conveniently merged bit-by-bit into the gcj front-end itself where it belongs.
One downside is the longer release cycle for the GCC RPM but this script is now in bug-fix mode so release frequency isn't as important.
rebuild-gcj-db --------------
This script's logic will be moved into a gcj-dbtool --rebuild option. I'm going to suggest we break compatibility (technically) by not providing a replacement rebuild-gcj-db script for use by old RPMS, just in the interest of not maintaining an extra script indefinitely.
We haven't decided yet who will do this work; Andrew Haley?
rebuild-security-providers --------------------------
I'm going to remove this script from jpackage-utils. I agree with David Walluck's argument that there aren't enough security provider RPMs available to warrant an extra script (and divergence from upstream jpackage-utils).
Until Jesse and GNU Crypto are merged into GNU Classpath I'll simply in- line the logic in rebuild-security-providers in those packages. I'm hoping to have them merged before Fedora Core 5 anyway.
Tom
Thomas Fitzsimmons wrote:
rebuild-gcj-db
This script's logic will be moved into a gcj-dbtool --rebuild option.
While we're changing things here I'd like to propose that the global database be moved from /usr/lib/gcj-x.y.z/classmap.db to somewhere like /var/lib/gcj/classmap.db. Unlike the per-package files the the global database is machine-specific, so putting it in /var makes us more LSB-compliant. One practical advantage of this is that it would allow our rpms to be used on systems with readonly /usr partitions.
Cheers, Gary
On Fri, 2005-11-11 at 08:48 +0000, Gary Benson wrote:
Thomas Fitzsimmons wrote:
rebuild-gcj-db
This script's logic will be moved into a gcj-dbtool --rebuild option.
While we're changing things here I'd like to propose that the global database be moved from /usr/lib/gcj-x.y.z/classmap.db to somewhere like /var/lib/gcj/classmap.db. Unlike the per-package files the the global database is machine-specific, so putting it in /var makes us more LSB-compliant. One practical advantage of this is that it would allow our rpms to be used on systems with readonly /usr partitions.
Good point. I filed two bugs for this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24798 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172950
Tom
java-devel@lists.fedoraproject.org