Bug 1022184 - libguestfs: do not use versioned jar file
libguestfs: do not use versioned jar file
Status: CLOSED NOTABUG
Product: Virtualization Tools
Classification: Community
Component: libguestfs (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard W.M. Jones
:
Depends On:
Blocks: 1022133
  Show dependency treegraph
 
Reported: 2013-10-22 12:20 EDT by Richard W.M. Jones
Modified: 2013-10-22 16:16 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1022133
Environment:
Last Closed: 2013-10-22 16:16:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2013-10-22 12:20:17 EDT
+++ 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
@PACKAGE_NAME@-@PACKAGE_VERSION@.jar.

Is now:

$ ls -1 java/*.jar
java/libguestfs-1.25.0.jar

should be:

java/libguestfs.jar
Comment 1 Stanislav Ochotnicky 2013-10-22 12:47:29 EDT
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 12:56:05 EDT
Oh, just as well I didn't push this patch then!
https://github.com/libguestfs/libguestfs/commit/7330ccd288a001d33866308ff8d679a884230d83

/me reverts it ...
Comment 3 Richard W.M. Jones 2013-10-22 12:57:12 EDT
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 13:09:00 EDT
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 16:16:54 EDT
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.