Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development Java (http://www.linux-archive.org/fedora-development-java/)
-   -   Packaging guidelines - do we need to repack jars for noarch Java packages? (http://www.linux-archive.org/fedora-development-java/160178-packaging-guidelines-do-we-need-repack-jars-noarch-java-packages.html)

Thomas Fitzsimmons 09-15-2008 06:43 AM

Packaging guidelines - do we need to repack jars for noarch Java packages?
 
Sean Flanigan <sflaniga@redhat.com> writes:

> G'day!
>
> I've been creating a package for eclipse-nls
> <https://bugzilla.redhat.com/show_bug.cgi?id=456972>, and I added this
> to my spec file:
>
> # Disable repacking of jars, since it takes forever for all the little
> jars,
> # and we don't need multilib anyway:
> %define __jar_repack %{nil}
>
> I haven't found a good explanation of the reasons behind jar repacking,
> but I gather it's something to do with multilib. What happens if you
> don't repack when you should?
>
> Jar repacking is incredibly slow when you have lots of little plugins
> (hello Eclipse!), so avoiding it is nice.
>
> I'm pretty sure it's safe to skip repacking in my case, because my
> package contains nothing except .properties files inside Eclipse plugins
> which are in jars when I download them, but is it safe to do in more
> general cases, such as noarch packages?
>
> Is there anything useful we could add to the guidelines?

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

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

Thomas Fitzsimmons 09-16-2008 11:01 AM

Packaging guidelines - do we need to repack jars for noarch Java packages?
 
Sean Flanigan <sflaniga@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

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list


All times are GMT. The time now is 09:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.