Bug 1022184 - libguestfs: do not use versioned jar file
Summary: libguestfs: do not use versioned jar file
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
Depends On:
Blocks: 1022133
TreeView+ depends on / blocked
Reported: 2013-10-22 16:20 UTC by Richard W.M. Jones
Modified: 2013-10-22 20:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1022133
Last Closed: 2013-10-22 20:16:54 UTC

Attachments (Terms of Use)

Description Richard W.M. Jones 2013-10-22 16:20:17 UTC
+++ This bug was initially created as a clone of Bug #1022133 +++

The upstream jar file apparently shouldn't contain a version
number, ie. it should be called @PACKAGE_NAME@.jar instead of

Is now:

$ ls -1 java/*.jar

should be:


Comment 1 Stanislav Ochotnicky 2013-10-22 16:47:29 UTC
Just to make sure this is not misunderstood: Upstream *SHOULD* produce versioned jar files. I hope you will *not* change that. It's only in RPMs that we have to have unversioned jar files. Otherwise our automatic requires generators can accidentaly create requires on versioned jar instead unversioned. 

No other tools can actually use versioned jar files and they are just additional inodes on filesystem.

Comment 2 Richard W.M. Jones 2013-10-22 16:56:05 UTC
Oh, just as well I didn't push this patch then!

/me reverts it ...

Comment 3 Richard W.M. Jones 2013-10-22 16:57:12 UTC
OK, I reverted that.  Is there somewhere which explains
what all this versioned/unversioned stuff means?   It
seems strange to put a version number in a jar file name.

Comment 4 Stanislav Ochotnicky 2013-10-22 17:09:00 UTC
I could probably dig up some JPackage guidelines that used to be de-facto standard for Java packaging in RPM world. Generally upstream java projects produce XX-%{version}.jar jar files during build and they don't deal with installation at all (unlike libguesfs...)

What was then done in rpm was that the versioned file was installed into /usr/share/java/ and an unversioned symlink was created so that other applications/libraries could safely use it without worrying that every version change is going to change the path.

Few releases back in Fedoraland we realized that no tooling or scripts are actually using %{version}.jar so they were removed (saving inodes and speeding up directory traversal). Later on we realized that now we could support compatibility packages this way. So if there *is* a versioned symlink we assume that it's a compatibility jar file (and unversioned is most likely completely different version). 

This ties into our autorequires generator and so your %{version}.jar could in theory trip it up. In your case that's not actually possible, but the versioned bug is still a problem because no application can safely use it (because it changes with each rebase)

Ideally? You'd produce versioned jar file during build and then install unversioned jar. That way other distributions (Debian) can still easily add additional versioned symlinks if they so choose and you won't have to fiddle with spec file in Fedora/RHEL

Comment 5 Richard W.M. Jones 2013-10-22 20:16:54 UTC
OK in that case I will close this bug and just do a change
to the spec file (bug 1022133).  Thanks for the explanation.

Note You need to log in before you can comment on or make changes to this bug.