[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_JNI

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&group_id=118012&atid=679788>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-java-list/attachments/20080916/104b4e6e/attachment.sig>