Followup: aot-compile-rpm, rebuild-gcj-db and rebuild-security-providers

[Thomas Fitzsimmons]

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

[Gary Benson]

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

[Thomas Fitzsimmons]

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