https://bugzilla.redhat.com/show_bug.cgi?id=2283055 --- Comment #39 from Daniel Berrangé <berrange@xxxxxxxxxx> --- > > It does bring up a question of versioning though, which I wanted to clarify > > before proceeding. The upstream version is a tag on a branch that contains > > patches to make packaging easier, as per your earlier suggestion. It has an > > upstream version number '1.0.1-2'. As such, would the RPM version be '1.0.1' > > (and release '2'), or would it be '1.0.1-2' and the release whatever Fedora > > assigns, so the RPM may have a version number such as '1.0.1-2-1'? (I feel > > the latter is the more appropriate, but I'd like you to confirm). > > > > '1.0.1-2-1' would not be a valid NVR. You could however do '1.0.1.2-1' (1.0.1.2 version and 1 release) if you think it doesn't worth to release a '1.0.2' bugfix version. What this special "1.0.1-2" tag has done is to effectively create a different versioning scheme for bug fix releases (4 digits) vs normal releases (3 digits). Valid, but unusual and undesirable IMHO. If this "1.0.1-2" tag was a one-off very special edge case, I'd be inclined to pretend that this tag doesn't exist, and just use the original '1.0.1' version in the RPM as the latest .spec has done, on the basis that the RPM will update to 1.0.2 eventually making the special case disappear for Fedora. If upstream /wants/ the ability in future to create bug-fix releases on stable branches, then I'd suggest to consider changing the upstream version numbering practices. Have the normal releases bump the middle digit (1.1.0, 1.2.0, 1.3.0, 1.4.0, etc), and leave the minor digit as '0', reserved in case you need a bug fix release (1.1.1, 1.1.2, 1.1.3, etc) on a branch. If this is desired, it isn't a blocker for adding the Fedora RPM, and again we ca just use '1.0.1' as the version in the RPM for now. > > 1. Let it be as such, if that's OK. (The Debian package has passed the > > initial reviews and is moving to testing with the same setup.) > > 2. I can define weak dummy implementations of the `jplint_` and `jplihp` > > symbols that simply return an error. That would cure the rpmlint errors, but > > it would also hide the fact that the `solsys2` plugin really requires these > > symbols be defined by the user-code. This would probably also mean that I'd > > have to create a new upstream branch/tag (e.g. 1.0.1-3) to distinguish it > > from the one used by the Debian package. > > 3. Drop providing the `solsys2` plugin as a library altogether, and supply > > the source code as documentation (examples) only. This is fine, but it > > requires a bit of extra work for people who want to link their existing > > (old) code with the `solsys2` functionality. > > > > What would be your solution? > > I think that if that is expected, it should be fine. But I don't know much about C programming/linking, so I'll ask for some advice by more skilled users on how to deal those errors. I think (1) is acceptable. This is certainly unusual / not best practice, but if this is the way the library has been *intentionally* designed to work, then it is not for Fedora to tell upstream to re-write their code. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2283055 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202283055%23c39 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
