Bug 1022184
| Summary: | libguestfs: do not use versioned jar file | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Richard W.M. Jones <rjones> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | acathrow, mbooth, rjones, sochotni, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1022133 | Environment: | |
| Last Closed: | 2013-10-22 20:16:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1022133 | ||
|
Description
Richard W.M. Jones
2013-10-22 16:20:17 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. Oh, just as well I didn't push this patch then! https://github.com/libguestfs/libguestfs/commit/7330ccd288a001d33866308ff8d679a884230d83 /me reverts it ... 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. 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
OK in that case I will close this bug and just do a change to the spec file (bug 1022133). Thanks for the explanation. |