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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/