[fedora-java] Moving aot-compile-rpm and rebuild-gcj-db out of java-gcj-compat

[Thomas Fitzsimmons]

Hi,

Making aot-compile-rpm and rebuild-gcj-db alternatives symlinks was
obviously a mistake, but I think putting them in java-gcj-compat at all
is also a mistake.  I'm currently looking for other places to move them.

A comment in aot-compile-rpm raises the possibility of including this
script in RPM itself.  Gary, do you think this is feasible in the FC5
time frame?

I also propose removing rebuild-gcj-db and instead adding a --rebuild
argument to gcj-dbtool that implements the current Fedora Core database
management policy (which seems to work).  Andrew and Tom, thoughts?

The last gcj-specific script in our JPackage stack is
rebuild-security-providers.  I'd also like to get rid of it, but I'd
like to know what others think first.

I added rebuild-security-providers so that java security provider RPMs
could easily make GCJ aware of the new provider.  Ideally, JPackage
would provide a JVM-neutral mechanism for this, but it seems like it
would be a lot of work (i.e. you'd likely need to partition the
available providers based on JVM vendor and version -- a global
java.security file likely wouldn't work).

Do people think it's worth having a gcj-specific script in
jpackage-utils to make gcj aware of new security provider RPMs?  Do the
JPackage people reading this list know of a better, more general
solution?  (I'm not even sure it's worth worrying about this, since (the
few existing) security provider packages could easily manually
add/remove themselves to/from whichever java.security file they care
about).

Anyway, I was considering creating an intermediate
java-gcj-compat-scripts package to handle these scripts but looking
through them, I think it's better to get rid of them during the push to
FC5.  Doing so will solve the "missing rebuild-gcj-db" failures.

Comments welcome,

Tom