[fedora-java] Re: Packaging guidelines - do we need to repack jars for noarch Java packages?

[Sean Flanigan]

Thomas Fitzsimmons wrote:
>  brp-java-repack-jars is meant to eliminate multilib conflicts for
>  arch-dependent packages that include both arch-independent JARs under
>  /usr/share/java and GCJ-compiled .jar.sos under /usr/lib*.  JAR encodes
>  a timestamp in archives it produces, so RPM's checksum-based conflict
>  detection algorithm forbids installation of two otherwise identical JARs
>  built at different times.  Such conflicts affect Java packages that
>  provide GCJ support.  The problem doesn't exist for noarch Java
>  packages.
>  
>  A small number of Java packages must be built arch-specific -- even if
>  they do not provide GCJ support -- because they contain JNI DSOs.
>  Running brp-java-repack-jars would seem to be necessary for these
>  packages, except that the Java guidelines specify that JNI-using JAR
>  files should be installed in %{_libdir}/%{name} [1].
>  
>  The short answer is: if you follow the Java packaging guidelines, you
>  only need to run brp-java-repack-jars on packages that include
>  arch-independent JAR files under /usr/share and that also include
>  GCJ-compiled .jar.so files.  So ideally brp-java-repack-jars should not
>  be run by default, but should instead be rolled into aot-compile-rpm.
>  That would eliminate "%define __jar_repack %{nil}" spec file hacks.
>  
>  Tom
>  
>  1. http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use... 
Thanks for the explanation, Tom.  I think I got most of it, with help
from an interpreter.

So, a jar only needs to be repacked if (a) it is destined for
/usr/share/ and (b) it belongs to an arch-specific package.  Have I got
that right?

It sounds like repacking would be totally unnecessary if /usr/share/
jars were required to be in noarch sub-packages.  Is that too
impractical?  (I'm new to packaging.  Can you tell?)

BTW, next time someone is looking at brb-java-repack-jars, they might
want to check the status of this patch against Info-Zip:
<http://sourceforge.net/tracker/index.php?func=detail&aid=2105163&...

It's a patch for zipnote which can edit the timestamps inside a zip
file.  At the moment, it works on jar files (I just checked - the
checksums match!), but ordinary zip files tend to have other timestamps
which aren't handled yet.  And my quick port to Zip 3.0 segfaults, I
just discovered.

brb-java-repack-jars could use the patched zipnote to edit the
timestamps without having to repack the jars, but I suppose there's more
benefit in the aot-compile-rpm work mentioned above.  Still, once Zip
3.1 becomes available to the Fedora build system, it would be pretty
easy to change brb-java-repack-jars.  Assuming the patch, or something
like it, makes it into Zip 3.1, that is.

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat