[fedora-java] libvirt-java bindings

[Daniel Veillard]

On Tue, Jul 01, 2008 at 12:24:49PM -0400, David Walluck wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel Veillard wrote:
> | I would like something more flexible, to that end I added some JDK dynamic
> | detection in configure.in for my package, which then allows to guess the
> | jni.h and jni_md.h based on the javah and javac used to generate the
> bindings
> | (so things should stay consistent).
> | In the spec file I used the following:
> 
> There is no need since java and java-devel are virtual Provides provided
> by every compliant JDK, so the user is already allowed to choose the JDK
> that they want to build with.
> 
> Also, there are macros that should be used when refering to the JDK so
> that you pick up the default JDK used for building and not the current
> default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}).

  Hum, interesting, butthat's very dependant on the build environment.
For example if I rebuild the RPM for RHELv4 those macro define won't exist
I don't think I should rely on this for a really generic spec file.

> Unfortunately, there are recent packages passing the Fedora review that
> directly specify java-1.6.0-openjdk-devel as the JDK and I personally
> don't like this.
> 
> I think that this comes from two schools of thought: one group wants to
> tie the Fedora package even more tightly to Fedora and the other wants
> to leave the options open. Since Fedora more-or-less has only one JDK
> (or two counting GCJ which is optional), this benefit is mostly
> theoretical, but you can see from the current discussion that it can be
> useful. Similarly, since Fedora can force the default JDK setup at build
> time through the build system, although the packages are technically not
> as flexible as they could be, it's never really a problem in practice.

  I think the distro build can already define its own policy of what
package should be used when there is a java/java-devel BuildRequires
just by the way it selects the package used to create the build root.
So %{java_home}, %{java}, %{javac}, %{jar} to me are in a sense redundant
in that enviroment.
And outside of the distro build the macros are not available and that's
where the user selection should be done, so this doesn't help much in the
case of a manual user rpmbuild, except maybe if one uses them to override
the alternative default. 
  I guess I need to think a bit more about it, but i'm firmly in the camp
of those who think the package should be distribution agnostic as much as
possible.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/