-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas Fitzsimmons wrote:
> 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?
Hi Tom.
Gary has already gotten a portion of this process into rpm, only it's
not being used by default. If we're going to put it in, we also need the
logic to (easily) enable it in the macros file for a particular
distribution, or better, from a particular .spec.
I am disappointed that no one was interested in a discussion of moving
the natifying outside of the specific rpm, but I have just given up on
this idea. I certainly don't have the time or desire to implement it myself.
But the issue here is that (1) any distro will be picking up the gcj
policy so the script needs to be in rpm and usable (2) newer JPackage
versions will trump (kill) the nativified versions. It is because of (2)
that I think the FC ``solution'' is a very poor one, but given that I
have accepted that, I have no problem with (1) if rpm proper has the
support.
Also, I thought aot-compile was a good script, but it was done away
with. Wouldn't it make sense to bring this back and have a script that
didn't rely on rpm, and then have rpm call this script instead? This
way, not only other RPM-based distros, but possibly Debian or Ubuntu
could even pick it up.
> 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 don't see the harm in keeping it, but such a script might be useful
upstream for either classpath or gcj, or both. Apparently, they don't
share the same location for the classpath.security file (%{_prefix}/lib
vs. %{_libdir}), but it makes sense to see what the people involved
upstream think about this.
By the way, I did modify the script to ignore certain obvious patterns:
*.rpmsave|*.rpmorig|*.rpmnew|*~|*.orig|*.bak)
;;
> 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).
You have the right idea. This is the kind of thing we'd want in an ideal
world. Really, there is no problem is not having a global java.security
file, as it would be possible to rebuild these even on the fly provided
java was always ``properly'' invoked through JPackage utils. But given
that `java' is a binary, not a script, this can't work from the
command-line. Finally, since providers need to be signed, JPackage can't
even provide their own versions of providers for commercial Java
environments.
Let's turn away from our ideal world to the practical world. How many
providers do we have anyway? The default gcj one would essentially
always be there. We also have bouncycastle (I have package a pre-1.31
version, if anyone is interested). So what are the chances of the gcj
provider database needing to be updated? What if the file were static?
Can't a missing class be (silently) ignored? Then we could even have a
static list. Just for reference, mine currently looks like:
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=gnu.java.security.provider.Gnu
security.provider.3=org.metastatic.jessie.provider.Jessie
security.provider.4=gnu.crypto.jce.GnuCrypto
Do we really foresee anymore? If there are, just update the
classpath.security file once (the problem is which package should own
it). Ordering is up to a distro I suppose. Bouncycastle is clearly the
most complete.
> 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.
The key is that before we can do away with the scripts package, the
aot-compile script must be in rpm proper, as more than just FC relies on
them. The same goes for the gcc option, and a gcc release isn't
happening right away. In short, we need the scripts package for the time
being.
- --
Sincerely,
David Walluck
<david@xxxxxxxx>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDcsGCarJDwJ6gwowRAj3QAJ42Q4Ovjmaj+1HPsxNzZhpVpBEvAACeOgCn
GPS79FIDvT4kikugfV4ciNg=
=f0SP
-----END PGP SIGNATURE-----
