Sean Flanigan <sflaniga@xxxxxxxxxx> 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
--
fedora-devel-java-list mailing list
fedora-devel-java-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
