https://bugzilla.redhat.com/show_bug.cgi?id=2227804 --- Comment #17 from Matthieu Saulnier <casper@xxxxxxxxxxxxxxxxxx> --- (In reply to Jerry James from comment #14) > Issues > ====== > - My reading of the Snapshots part of the Versioning guide: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ > #_snapshots > is that the snapshot part goes in the Version field, not the Release field. Fixed. > > - I would also like to recommend that you use %autorelease and %autochangelog > instead of handling them manually. This is up to you, however. Will make it for all of my packages. (Just not today). > > - It looks like the code in the ref10 directory is public domain. In that > case, > the license field must be "MIT AND LicenseRef-Fedora-Public-Domain", along > with a comment about the license breakdown. Indeed. I apologies for this one, I was so bad. > > - Since ref10 is bundled, should the main package contain > "Provides: bundled(ref10)"? This package is not a bundle of a library. ref10 is XedDSA. And libxeddsa is the system-library for it. I believe all programs which will require XedDSA will require "libxeddsa.so.2()(64bit)" which is provided by my package. (In reply to David Timms from comment #15) > (In reply to Jerry James from comment #14) > > - My reading of the Snapshots part of the Versioning guide: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ > > #_snapshots > > is that the snapshot part goes in the Version field, not the Release field. > I don't think that is correct Jerry. > > However, Matthieu: in the value: > Release: 4^%{snapdate}git%{shortcommit}%{?dist} > , what is the caret do/for ? > In the past, it would be '.', and '^' wouldn't be allowed. Some examples > (from rpm-specs.latest.tar.xz (form 2023-12-24)): > yosyshq-abc.spec:Release: 1.%{snapdate}git%{shortcommit0}%{?dist} > > And if the source is pre-release, then perhaps a leading '0.' as in the > following egs: > catalyst.spec:Release: 0.7.20201218git%{shortcommit}%{?dist} > calypso.spec:Release: 0.12.%{date}git%{shortcommit}%{?dist} > js-jquery-ui-touch-punch.spec:Release: 0.15.20141219git%{shortcommit}%{?dist} > > So maybe version-release should expand to be: 2.0.0-0.4.20230824git1140086 > > Also, seems like there is newer commits/snapshots which could/should be used > instead? > What do you think Jerry? The only answer I can provide here is more context: When I started to make the package of libxeddsa, there was tarballs, for the 2.0.0 version plus some older. Then, there was some commits added, arround the lib but not in the lib itself. In this scenario, if I take a git snapshot, I'm in the "Post-release scenario". The Guideline has been changed and has evolved by the time. Please have a look at this section of the Guideline : "Traditional versioning with part of the upstream version information in the Release field" (everything is in the title). Ref: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#traditional-versioning One day, upstream decided to delete all tarballs from github, and keep only the git repository. The conversations of this topic was in Jabber chatrooms. The version 2.0.0 remains in the git history, so I kept the post-release scenario for my package. Many thanks Jerry, for the review. You are right, I was wrong :-) Here is the new release. Spec URL: https://fantom.fedorapeople.org/libxeddsa.spec SRPM URL: https://fantom.fedorapeople.org/libxeddsa-2.0.0%5e20240426gitd725c81-5.fc39.src.rpm -- 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=2227804 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202227804%23c17 -- _______________________________________________ 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
