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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux