https://bugzilla.redhat.com/show_bug.cgi?id=1432214 --- Comment #12 from Lokesh Mandvekar <lsm5@xxxxxxxxxx> --- (In reply to Adam Miller from comment #11) > (In reply to Lokesh Mandvekar from comment #9) > > Generic: > > [x]: Package is licensed with an open-source compatible license and meets > > other legal requirements as defined in the legal section of Packaging > > Guidelines. > > [x]: License field in the package spec file matches the actual license. > > Note: Checking patched sources after %prep for licenses. Licenses > > found: "MIT/X11 (BSD like)", "BSD (3 clause)", "Apache (v2.0)", > > "Unknown or generated", "*No copyright* Apache (v2.0)". 225 files have > > unknown license. Detailed output of licensecheck in > > /home/lsm5/repositories/pkgs/reviews/1432214-reg/licensecheck.txt > > > > --- Main source uses the MIT license. > > > > [x]: License file installed when any subpackage combination is installed. > > [x]: %build honors applicable compiler flags or justifies otherwise. > > [x]: Package contains no bundled libraries without FPC exception. > > > > --- I'll okay this given that golang tools are too painful to be built with > > unbundled libraries and unbundling produces no apparent benefit (IMHO). If > > anybody disapproves, I welcome them to unbundle deps themselves. > > > > [x]: Changelog in prescribed format. > > [x]: Sources contain only permissible code or content. > > [-]: Package contains desktop file if it is a GUI application. > > [x]: Development files must be in a -devel package > > [x]: Package uses nothing in %doc for runtime. > > [x]: Package consistently uses macros (instead of hard-coded directory > > names). > > [x]: Package is named according to the Package Naming Guidelines. > > [x]: Package does not generate any conflict. > > [!]: Package obeys FHS, except libexecdir and /usr/target. > > > > --- I see config(noreplace) in /etc/sysconfig/reg-server and > > /var/lib/reg-server . Is it possible they could be placed in /etc/reg-server > > instead. Just that I do remember people discouraging the use of > > /etc/sysconfig/blah in favor of /etc/blah. (I'll post the link to packaging > > guidelines for this if any exists) > > > > That is true if the configuration file is for the actual service. The > configuration values here are fed into the systemd unit. However if this has > changed and /etc/sysconfig/ has fallen out of favor for this scenario as > well I'll gladly switch it. I was mostly following along with what other > prominent software written in golang are doing such as docker and > kubernetes. You're right as per https://fedoraproject.org/wiki/Packaging:Systemd#.5BInstall.5D and lol at myself for having gotten that mixed up. So, [x]: Package obeys FHS, except libexecdir and /usr/target <- that LGTM > > > > [-]: If the package is a rename of another package, proper Obsoletes and > > Provides are present. > > [x]: Requires correct, justified where necessary. > > [x]: Spec file is legible and written in American English. > > [x]: Package contains systemd file(s) if in need. > > [!]: Useful -debuginfo package or justification otherwise. > > > > --- please generate this as per jchaloup's comment above. > > > > [x]: Package is not known to require an ExcludeArch tag. > > [-]: Large documentation must go in a -doc subpackage. Large could be size > > (~1MB) or number of files. > > Note: Documentation size is 204800 bytes in 6 files. > > [x]: Package complies to the Packaging Guidelines > > > > > > Additionally, could you also please post a successful scratch build URL? > > Will do. Also, jchaloup mentioned devel and unit-test-devel, that's if you include the original source code of the reg package in the -devel package. Take a look at the 'docker-devel' and 'docker-unit-test-devel' package for example. (I'm personally not a fan of golang -devel packages, and I think we're now left with 150+ of those packages which will sadly be left unmaintained). So, feel free to not create those since those are optional anyway. -- 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
