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
