FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development Java

 
 
LinkBack Thread Tools
 
Old 09-11-2008, 02:41 AM
Sean Flanigan
 
Default Packaging guidelines - do we need to repack jars for noarch Java packages?

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?

Regards

Sean.
--
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 09-16-2008, 03:17 AM
Sean Flanigan
 
Default Packaging guidelines - do we need to repack jars for noarch Java packages?

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

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

Thread Tools




All times are GMT. The time now is 08:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org