https://bugzilla.redhat.com/show_bug.cgi?id=1821987 --- Comment #4 from Richard Shaw <hobbes1069@xxxxxxxxx> --- Ok, first level spec review... 1. Is this a post release of 0.2.4 or a pre-release of 0.2.5? If it's a pre-release then the beginning of the Release: tag should be <1, so this would be appropriate: 0.1.%{snapshotdate}git%{shortcommit}%{?dist} You would increment the 0.1 to 0.2 if you build another pre-release, etc. That way when 0.2.5 final is released it will reset to 1. 2. Minor nit... The Summary is the same as %description, so you COULD use ust "%{summary}." but ideally the description would well, be more descriptive. 3. You should unbundle tinyxml is possible. While the restriction on use of bundled libraries has been reduced A LOT in the last few years it's still a best practice to use the system ones if practical. As the maintainer of a lot of CMake projects, it's usually pretty easy unless upstream has intentionally obfuscated their config. 4. BuildRequires: nit... It's best practice to list them one per line HOWEVER, I'm not that pedantic but I generally only group together ones that are related, e.g.: BuildRequires: cmake gcc-c++ desktop-file-utils # Library dependencies BuildRequires: SoapySDR-devel BuildRequires: wxGTK-devel BuildRequires: hamlib-devel BuildRequires: fftw-devel BuildRequires: rtaudio-devel BuildRequires: liquid-dsp-devel >= 1.3.2 5. Interesting you have to tell cmake where wx-config is even though which finds it just fine... May be a good idea in the long run to fix CMake and send the patch upstream. 6. Not really a packaging guidelines violation, but it may be best if you need a bash script to load it to move the binary to /usr/libexec instead or renaming to %{name}.bin. 7. There's no requirement to use %dir if you're just going to glob everything in it, just use a trailing forward slash so: %dir %{_datadir}/cubicsdr %{_datadir}/cubicsdr/* Becomes: %{_datadir}/cubicsdr/ 8. One more minor nit, the guidelines the spec file should be "readable" but doesn't specify everything that makes it "readable". I usually add two newlines between major sections of the spec file, (%prep, %build, %install, % files, %changelog). -- 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 _______________________________________________ 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
