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
