Bug 1578106 - Package version is invalid, or no Source URL provided
Summary: Package version is invalid, or no Source URL provided
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nspr
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daiki Ueno
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-14 19:47 UTC by greg.hellings
Modified: 2018-09-21 05:27 UTC (History)
4 users (show)

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:
Clone Of:
Environment:
Last Closed: 2018-09-14 23:12:31 UTC


Attachments (Terms of Use)
Patch to specfile (1.16 KB, patch)
2018-05-14 19:49 UTC, greg.hellings
no flags Details | Diff

Description greg.hellings 2018-05-14 19:47:42 UTC
Description of problem:
The version of NSPR that is claimed is 4.19.0. There is no upstream release 4.19.0 in the release directory that I can find (https://ftp.mozilla.org/pub/nspr/releases/). If there is a different upstream release directory, that should be specified by the Source0 path (this URL should also be included, as well)


Version-Release number of selected component (if applicable):
4.19.0-1


How reproducible:
Always


Steps to Reproduce:
n/a

Actual results:
4.19.0


Expected results:
4.19

Comment 1 greg.hellings 2018-05-14 19:49:28 UTC
Created attachment 1436543 [details]
Patch to specfile

Attached patch adds full source URL to the spec file and corrects the version number.

Comment 2 Kai Engert (:kaie) (inactive account) 2018-05-24 18:36:26 UTC
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.

Comment 3 Kai Engert (:kaie) (inactive account) 2018-05-24 18:39:21 UTC
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?

Comment 4 greg.hellings 2018-06-19 04:39:25 UTC
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.

Comment 5 Daiki Ueno 2018-06-27 08:03:54 UTC
(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.

Comment 6 Elio Maldonado Batiz 2018-06-27 15:00:40 UTC
(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.

Comment 7 Daiki Ueno 2018-06-29 07:57:01 UTC
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?

Comment 8 Kai Engert (:kaie) (inactive account) 2018-06-29 12:32:53 UTC
Thank you Elio, this was very helpful.

Comment 9 Elio Maldonado Batiz 2018-06-30 00:44:46 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=981166#c3

Comment 10 Daiki Ueno 2018-07-04 09:36:43 UTC
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/).

Comment 11 Kai Engert (:kaie) (inactive account) 2018-07-17 15:48:23 UTC
Daiki, IIUC, you decided this is wontfix, correct?

Comment 12 greg.hellings 2018-07-17 16:02:16 UTC
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.

Comment 13 Daiki Ueno 2018-07-17 16:10:50 UTC
For the spec file update, I was actually thinking to do the adjustment automatically.  See:
https://src.fedoraproject.org/rpms/nspr/pull-request/2

Comment 14 Jan Kurik 2018-08-14 10:02:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 15 Fedora Update System 2018-09-04 11:10:04 UTC
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

Comment 16 Fedora Update System 2018-09-04 11:10:20 UTC
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

Comment 17 Fedora Update System 2018-09-04 11:10:36 UTC
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

Comment 18 Fedora Update System 2018-09-05 21:26:29 UTC
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

Comment 19 Fedora Update System 2018-09-06 02:11:53 UTC
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

Comment 20 Fedora Update System 2018-09-07 00:05:54 UTC
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

Comment 21 Fedora Update System 2018-09-07 00:06:29 UTC
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

Comment 22 Fedora Update System 2018-09-14 23:12:31 UTC
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.

Comment 23 Fedora Update System 2018-09-18 07:52:25 UTC
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.

Comment 24 Fedora Update System 2018-09-21 05:27:23 UTC
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.


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