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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-java-list mailing list fedora-devel-java-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
