[fedora-java] Mending the Java native library mess before F10

Alexander Kurtakov akurtako at redhat.com
Tue Oct 21 20:47:02 UTC 2008


David Walluck wrote:
> Fernando Nasser wrote:
>> Can't we have the real JAR and the .so in %{_libdir}/%{name} as 
>> required by the guideline and add a symlink to the JAR (only) in 
>> /usr/share/java ?
>
> JPackage already provides a location for these jars, and this location 
> is searched by jpackage-utils. The location is %_jnidir, and it seems 
> to be defined as %_prefix/lib/java, but it should probably be 
> %_libdir/java.
>
> Contrast this with Debian which palces .so in /usr/lib/jni and the jar 
> in /usr/share/java.
>
> If JNI using JAR files are really not arch-specific, they should go in 
> %_javadir. I do not see why the Fedora guidelines place jars in 
> application-specific directories with the shared library itself.
>
> There are two issues:
>
> 1.) No one (Debian, Fedora, JPackage) can agree on the .jar location: 
> (i.) %_prefix/lib/java (ii.) %_libdir/java (iii.) %_javadir (iv.) 
> %_libdir/%name.
>
> 2.) If the .jar location is only (iv.) %_libdir/%name as in the Fedora 
> guidelines (no symlinks), then any specs or scripts that use 
> build-classpath on these jars would need to be re-written, and it is 
> not clear why they behave differently from all other jars in this way.
>
> And the JPackage specs and scripts automatically become incompatible.
>
Breaking compatibility with jpackage just for the change is stupid - at 
least I don't see any benefit. Breaking compatibility with nomatter what 
should bring some benefits otherwise we are doing work which bring us 
only more work and less features.
This also makes things harder for most packagers for several users:
1. Jpackage guidelines and tools are well known - most of the 
experienced packagers in the java area either have been part of the 
jpackage once are part now or at least  are  familiar with them. And I'm 
not speaking for Fedora guys only.
2. We make our specs harder to maintain - Using build-classpath frees 
you from details like whether the jar has native parts or not. But with 
the current policy - placing jars in %_libdir/%name if the jar adds some 
native parts you should change your spec file. Using build-classpath you 
just need to rebuild with no changes.
But wait - there is even more you can use build-classpath in your 
startup shell files so you even don't need to rebuild.
Please don't break compatibility with JPackage with some policy if you 
really don't have something  much better.

I completely support the following steps :
1. %_jnidir should be defined as %_libdir/java
2. All the jars with native parts should be installed in %_jnidir
3. jpackage-utils should be checked for needed modifications for this 
change.

Best regards,
Alexander Kurtakov






More information about the java-devel mailing list