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

[Thomas Fitzsimmons]

Sean Flanigan <sflaniga at redhat.com> writes:

> 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?

Yes.

> 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?)

We have discussed solutions like that before.  It used to be that
rpmbuild didn't allow multiple different BuildArch tags in a single spec
file.  I suspect that's still the case.

> 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.

Your zipnote patch sounds promising.  aot-compile-rpm should likely make
use of it when it's ready.  I'm glad to see someone's trying to
eliminate this annoyance.

Tom