https://bugzilla.redhat.com/show_bug.cgi?id=2121593 Jerry James <loganjerry@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(loganjerry@gmail. | |com) | --- Comment #2 from Jerry James <loganjerry@xxxxxxxxx> --- Thank you for the review! (In reply to Jonathan Wright from comment #1) > I've seen a lot of python packages start leaving out (sphinx) documentation > due to the complexity and licensing mess that ensues. Do you want to > consider that here? If you leave out docs then MIT covers it all. I like having local documentation so that I can keep working in that inevitable moment when the network goes away. I'm willing to sort through the complexity and licensing mess to achieve that. > > Version: 0.0.1 > > Release: 0.1.%{prerel}%{?dist} > > This isn't really the right way to do pre-release stuff. [1] Sure it is. Reference [1] says "In the Version: tag, use the version that upstream has determined the next release will be." That's 0.0.1. Then [1] says "For the field of the Release: tag, use a number of the form "0.N" where N is an integer beginning with 1 and increasing for each revision of the package." That's 0.1 for the initial package. As for reference [2], if you look at the example labeled "Example (pkg pre-release)" you will see it looks *exactly* like what I've got in this spec file, including the 3rd release field to indicate which prerelease version it is. This is the reason for the policy given in [1]: $ rpmdev-vercmp 0.0.1a12-1 0.0.1-1 0.0.1a12-1 > 0.0.1-1 $ rpmdev-vercmp 0.0.1-0.1.a12 0.0.1-1 0.0.1-0.1.a12 < 0.0.1-1 With version 0.0.1a12 and release 1, the final 0.0.1 release will sort *lower* than the alpha release. > > %{py3_dist X} > > Everywhere you're using this just do `python3-X` instead. It's far simpler. > What you're using is the OLD style which shouldn't be used anymore. [3] I don't see where you get that. The link you gave is to the old version of the Python guidelines. This is the current version: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/. It says nothing about avoiding py3_dist. In fact, it uses the word "useful" in conjunction with the py3_dist macro: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_manual_generation. > In fact you could use some newer macros in the %prep section instead to > automatically grab these things: > > %generate_buildrequires > %pyproject_buildrequires > > This should knock out almost all of your BRs at least outside of the %if > (except for python-devel of course which must stay). [4] Yes. I deliberately avoid use of automatically generated BuildRequires. The primary reason is that I maintain hundreds of packages, and have developed a workflow that involves grepping through spec files to help me manage dependency chains. Automatically generated BuildRequires hide those dependencies from grep. (A secondary reason is that it seems silly to use power-sucking computing resources to generate the same list over and over, instead of generating the list once and then caching it until something changes that might require the list to be regenerated.) > > %autosetup -n sphinx-basic-ng-%{version}.%{prerel} -p1 > > Will need to be corrected after dropping prerel above. Version in > %changelog as well of course. No change needed as the spec file is correct in this regard. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2121593 _______________________________________________ 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
