Bug 1578106
Summary: | Package version is invalid, or no Source URL provided | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | greg.hellings | ||||
Component: | nspr | Assignee: | Daiki Ueno <dueno> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 29 | CC: | dueno, elio.maldonado.batiz, kengert, stransky | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | nspr-4.20.0-1.fc28 nspr-4.20.0-1.fc27 nspr-4.20.0-1.fc29 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-09-14 23:12:31 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
greg.hellings
2018-05-14 19:47:42 UTC
Created attachment 1436543 [details]
Patch to specfile
Attached patch adds full source URL to the spec file and corrects the version number.
Hello Greg. Fedora version 4.19.0 corresponds to upstream version 4.19 Upstream prefers to omit the .0 But for Fedora version tracking, we had decided in the past that adding the .0 can avoid trouble with package management tools when comparing package version numbers. I'd prefer to avoid these changes. Is there any Fedora guideline that strictly requires us to use the direct full URI to an upstream tar ball? There is a pretty strict guideline for following the upstream versioning, according to the package guidelines. https://fedoraproject.org/wiki/Packaging:Versioning#Simple_versioning reads, "To package release versions of software using this versioning scheme: Use the upstream verbatim in the Version: tag. Don't trim leading zeroes..." In the absence of following that guideline, there is no comment or information in the spec file that allows me to deduce the pedigree or origins of the file that is being used, which makes it very difficult for me to figure out exactly what sources are being packaged. On the question of if a full URL should be used, https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections states that, "The Source: tags document where to find the upstream sources for the package. In most cases this SHOULD be a complete URL to the upstream tarball." Further information is then linked at https://fedoraproject.org/wiki/Packaging:SourceURL. This page begins by saying, "One of the design goals of rpm is to cleanly separate upstream source from vendor modifications. For the Fedora packager, this means that sources used to build a package should be the vanilla sources available from upstream." It continues by saying, "The most common case is where upstream distributes source as a tar.gz, tar.bz2 or zip archive that we can download from an upstream website. In these cases you must use a full URL to the package in the SourceX: line." If you're not following this, I presume there was an exception made at some point. However, by not at least mentioning this anywhere in the spec file, you make it impossible to even follow the track and pedigree of your code back through time without an overwhelming amount of work. I was finally able to verify your tarball was the same as upstream by unpacking it, then running diff across the sources. That amount of effort should not be required for a person to follow the source's trail. I mainly bring this all up because I maintain the mingw-nspr package. Our automated scripts keep flagging nspr/mingw-nspr as being different between the native and cross-compiled versions. I wanted to be sure that I was packaging the same thing, because the versions *seemed* to be the same, just differing in the absent trailing ".0". So the package guidelines do dictate that you need to use the same versioning scheme as upstream and include the full source URL to your files. I presume, like most things, exceptions can be granted but it would seem reasonable to include a mention of such an exclusion in the spec file if one were available. (In reply to Kai Engert (:kaie) from comment #2) > But for Fedora version tracking, we had decided in the past that adding the > .0 can avoid trouble with package management tools when comparing package > version numbers. Do you happen to remember what was the actual issue that this convention tries to avoid? In my experience, the number of components in a version doesn't matter at the package manager level; in other upstream projects, I sometimes create a paper bag release with a 4-component version number (X.Y.Z.P), while it usually uses 3-component version numbers (X.Y.Z), and that haven't cause any trouble in packaging. Thus I tend to agree with the proposal removing ".0". Note that, however, to proceed with the change we need to wait for a new release, because 4.19 < 4.19.0. (In reply to Daiki Ueno from comment #5) > (In reply to Kai Engert (:kaie) from comment #2) > > > But for Fedora version tracking, we had decided in the past that adding the > > .0 can avoid trouble with package management tools when comparing package > > version numbers. > > Do you happen to remember what was the actual issue that this convention > tries to avoid? > If I recall correctly it was due to upgrade problems Firefox experienced when NSS was being updated to a minor NSS release where we were using two-component version numbers instead of use of the tree-component version numbers used on patch releases. Martin Stransky reported the issue to us and he may remember things more clearly than I do. Thanks Elio for the hint; indeed, I see manual version checks in firefox.spec, though it uses two-component version numbers for patch releases these days. Martin, do you think if the trailing ".0" of nspr/nss versions is still necessary? Thank you Elio, this was very helpful. Thank you for the pointer. So to recap, the problem was: - Some dependent packages assume that the package version and the pkg-config version are equivalent and are using that fact to determine the build-time depenedency - However, before that bug was filed, the package version didn't match with the pkg-config version, when the trailing ".0" was omitted In that case, adding ".0" to always use three-component version numbers seems reasonable to me, given that nspr/nss internally use three-component version numbers (e.g., NSS_VMAJOR/NSS_VMINOR/NSS_VPATCH macros). It also conforms to the semantic versioning recommendations (https://semver.org/). Daiki, IIUC, you decided this is wontfix, correct? It should at least be fixed with a comment in the spec file. Currently the spec is out of order with the current guidelines in multiple respects surrounding this. If it's not going to be remedied, it should be mentioned why that is, how to fetch the upstream source, and how to transform it to match what the spec file expects. Ideally it should be resolved by updating the package to match the guidelines on the next upstream release. For the spec file update, I was actually thinking to do the adjustment automatically. See: https://src.fedoraproject.org/rpms/nspr/pull-request/2 This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'. nss-3.39.0-1.0.fc28 nss-softokn-3.39.0-1.0.fc28 nss-util-3.39.0-1.0.fc28 nspr-4.20.0-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1a7a5c54c2 nss-3.39.0-2.fc29 nss-softokn-3.39.0-2.fc29 nss-util-3.39.0-2.fc29 nspr-4.20.0-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c72d2d89ec nss-3.39.0-1.0.fc27 nss-softokn-3.39.0-1.0.fc27 nss-util-3.39.0-1.0.fc27 nspr-4.20.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4a21a8ca59 nspr-4.20.0-1.fc29, nss-3.39.0-2.fc29, nss-softokn-3.39.0-2.fc29, nss-util-3.39.0-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c72d2d89ec nspr-4.20.0-1.fc27, nss-3.39.0-1.0.fc27, nss-softokn-3.39.0-1.0.fc27, nss-util-3.39.0-1.0.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-4a21a8ca59 nspr-4.20.0-1.fc28, nss-3.39.0-1.0.fc28, nss-softokn-3.39.0-1.0.fc28, nss-util-3.39.0-1.0.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1a7a5c54c2 nspr-4.20.0-1.fc28, nss-3.39.0-1.0.fc28, nss-softokn-3.39.0-1.0.fc28, nss-util-3.39.0-1.0.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1a7a5c54c2 nspr-4.20.0-1.fc28, nss-3.39.0-1.0.fc28, nss-softokn-3.39.0-1.0.fc28, nss-util-3.39.0-1.0.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. nspr-4.20.0-1.fc27, nss-3.39.0-1.0.fc27, nss-softokn-3.39.0-1.0.fc27, nss-util-3.39.0-1.0.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. nspr-4.20.0-1.fc29, nss-3.39.0-2.fc29, nss-softokn-3.39.0-2.fc29, nss-util-3.39.0-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. |