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
Thomas Fitzsimmons wrote:
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?
I think thats a good idea. I see no reason why this shouldn't be rolled into gcj-dbtool (Andrew?). If needed for compatibility reasons, rebuild-gcj-db could be made to call "gcj-db --rebuild".
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.
I agree. The less packages the better, IMO.
Bryce
Bryce McKinlay wrote:
Thomas Fitzsimmons wrote:
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?
I think thats a good idea. I see no reason why this shouldn't be rolled into gcj-dbtool (Andrew?). If needed for compatibility reasons, rebuild-gcj-db could be made to call "gcj-db --rebuild".
There would have to be a %{_bindir}/rebuild-gcj-db in whatever provides gcj-db as without it none of the existing rpms could be uninstalled or upgraded.
Cheers, Gary
On Thu, 2005-11-10 at 09:57 +0000, Gary Benson wrote:
Bryce McKinlay wrote:
Thomas Fitzsimmons wrote:
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?
I think thats a good idea. I see no reason why this shouldn't be rolled into gcj-dbtool (Andrew?). If needed for compatibility reasons, rebuild-gcj-db could be made to call "gcj-db --rebuild".
There would have to be a %{_bindir}/rebuild-gcj-db in whatever provides gcj-db as without it none of the existing rpms could be uninstalled or upgraded.
With rebuild-gcj-db as an alternative I'm not sure this is even possible now (especially if gcj is not the currently-selected alternative). I think we can get away with "breaking backwards compatibility" here in the interest of not maintaining a "rebuild-gcj-db" script indefinitely.
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Fitzsimmons wrote:
With rebuild-gcj-db as an alternative I'm not sure this is even possible now (especially if gcj is not the currently-selected alternative). I think we can get away with "breaking backwards compatibility" here in the interest of not maintaining a "rebuild-gcj-db" script indefinitely.
It could have been fixed if it wasn't called unconditionally:
%post if [ -x %{_bindir}/rebuild-gcj-db ]; then %{_bindir}/rebuild-gcj-db fi
Unfortunately, now that the damage has been done, some manual intervention is likely necessary, since you can't uninstall, so the upgrade will fail. Or, you could install with `rpm --noscripts' (unless this only applied to the current package).
- -- Sincerely,
David Walluck david@zarb.org
Thomas Fitzsimmons wrote:
On Thu, 2005-11-10 at 09:57 +0000, Gary Benson wrote:
Bryce McKinlay wrote:
If needed for compatibility reasons, rebuild-gcj-db could be made to call "gcj-db --rebuild".
There would have to be a %{_bindir}/rebuild-gcj-db in whatever provides gcj-db as without it none of the existing rpms could be uninstalled or upgraded.
With rebuild-gcj-db as an alternative I'm not sure this is even possible now (especially if gcj is not the currently-selected alternative). I think we can get away with "breaking backwards compatibility" here in the interest of not maintaining a "rebuild-gcj-db" script indefinitely.
It doesn't have to be indefinite, but it will have to be there for FC5 and probably FC6 at least: without it upgrades from FC4 will fail and releng will kick our ass.
Gary
-----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@zarb.org
David Walluck writes:
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.
aot-compile-rpm doesn't rely on RPM at all -- it's just REALLY badly named! :-)
Andrew.
Andrew Haley wrote:
David Walluck writes:
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.
aot-compile-rpm doesn't rely on RPM at all -- it's just REALLY badly named! :-)
Not strictly true. It does have RPM-specific bits, but they're very very small: 10 lines out of 436. I spoke to some of the Debian and Ubuntu guys at DevJam about abstracting it but that's difficult to do whilst it's alternatives-managed.
Of course, doing this would make rpm a particularly bad home for it. The obvious place is in gcc itself (and aot-compile-rpm itself could either go there or in rpm) but that would mean being tied to gcc's necessarily slow release cycle.
Maybe the solution is having aot-compile-* in its own package. It seems overkill though...
Cheers, Gary
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gary Benson wrote:
Maybe the solution is having aot-compile-* in its own package. It seems overkill though...
I would say that they could be part of jpackage-utils if there is no other home for them. Sure, they do happen to be gcc-specifc, but at least they should be arch-agnostic.
- -- Sincerely,
David Walluck david@zarb.org
David Walluck wrote:
Gary Benson wrote:
Maybe the solution is having aot-compile-* in its own package. It seems overkill though...
I would say that they could be part of jpackage-utils if there is no other home for them. Sure, they do happen to be gcc-specifc, but at least they should be arch-agnostic.
Now there's an idea. It'd introduce a dependency on Python, though. I know it's nigh-on impossible to install a Fedora system without Python, so it's no big deal for us, but does the same apply for SuSE and Mandrake?
Cheers, Gary
Gary Benson writes:
Andrew Haley wrote:
David Walluck writes:
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.
aot-compile-rpm doesn't rely on RPM at all -- it's just REALLY badly named! :-)
Not strictly true. It does have RPM-specific bits, but they're very very small: 10 lines out of 436. I spoke to some of the Debian and Ubuntu guys at DevJam about abstracting it but that's difficult to do whilst it's alternatives-managed.
Of course, doing this would make rpm a particularly bad home for it. The obvious place is in gcc itself (and aot-compile-rpm itself could either go there or in rpm) but that would mean being tied to gcc's necessarily slow release cycle.
gcc doesn't seem to be having a very slow release cycle at the moment: we've seen GCC 4.0.2 in September, GCC 4.0.1 in July and GCC 4.0.0 in April.
I can't see any good reason not to move aot-compile-* to gcc, with a view eventially to make it unnecessary by folding all its functions into gcj itself.
Andrew.
Andrew Haley wrote:
Gary Benson writes:
The obvious place is in gcc itself (and aot-compile-rpm itself could either go there or in rpm) but that would mean being tied to gcc's necessarily slow release cycle.
gcc doesn't seem to be having a very slow release cycle at the moment: we've seen GCC 4.0.2 in September, GCC 4.0.1 in July and GCC 4.0.0 in April.
I meant the rpm. At the moment I can change a-c-r and push the packages out myself: I can't do that for gcc, and I'd have to wait the two weeks to a month until the next gcc rpm was built.
Cheers, Gary
On Thu, 2005-11-10 at 11:26 +0000, Gary Benson wrote:
Andrew Haley wrote:
David Walluck writes:
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.
aot-compile-rpm doesn't rely on RPM at all -- it's just REALLY badly named! :-)
Not strictly true. It does have RPM-specific bits, but they're very very small: 10 lines out of 436. I spoke to some of the Debian and Ubuntu guys at DevJam about abstracting it but that's difficult to do whilst it's alternatives-managed.
Making aot-compile-rpm alternatives-managed was a mistake on my part, and one of the reasons I started this discussion.
Tom
Thomas Fitzsimmons wrote:
On Thu, 2005-11-10 at 11:26 +0000, Gary Benson wrote:
I spoke to some of the Debian and Ubuntu guys at DevJam about abstracting it but that's difficult to do whilst it's alternatives-managed.
Making aot-compile-rpm alternatives-managed was a mistake on my part, and one of the reasons I started this discussion.
Yeah. I wasn't having a dig or anything (sorry if it sounded like it). I understand why you did it and stuff.
Cheers, Gary
On Thu, 2005-11-10 at 16:07 +0000, Gary Benson wrote:
Thomas Fitzsimmons wrote:
On Thu, 2005-11-10 at 11:26 +0000, Gary Benson wrote:
I spoke to some of the Debian and Ubuntu guys at DevJam about abstracting it but that's difficult to do whilst it's alternatives-managed.
Making aot-compile-rpm alternatives-managed was a mistake on my part, and one of the reasons I started this discussion.
Yeah. I wasn't having a dig or anything (sorry if it sounded like it).
Nah, I was just making sure you knew this wasn't still a design constraint.
Tom
David Walluck wrote:
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?
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.
Having natifying outside of specific rpms was my original intention:
https://lists.dulug.duke.edu/pipermail/rpm-devel/2005-July/000507.html
Indeed, aot-compile-rpm was specifically designed to be used in the same way as brp-python-bytecompile, though the --exclude option that everyone loves except me has broken this somewhat.
The problem with this is as I outlined in the above email, in that there are five things that need to happen for transparent native compilation, of which aot-compile-rpm is just one step (and the simplest at that). The two most tricky steps (adding %post/%postun scripts, and adding dependencies for same) were the ones I really wanted to automate, but Jeff Johnson's solutions were basically "do it manually".
Cheers, Gary
java-devel@lists.fedoraproject.org
-
Andrew Haley -
Bryce McKinlay -
David Walluck -
Gary Benson -
Thomas Fitzsimmons