https://bugzilla.redhat.com/show_bug.cgi?id=1886858 --- Comment #2 from code@xxxxxxxxxxxxxxxxxx --- Thank you very much for your time and your careful review. > I would still contact upstream and see what they have to say about it, and whether they're responsive at all. A reasonable request. I have emailed Greg Roelofs to provide the -Werror=format-security patch and the separate MIT license file suggestion upstream. I will comment again here if I receive a prompt response. > Worst case scenario, you can fork the project and add the missing components into your fork. I respect your suggestion. However, I have to say that I have never seen the Fedora guidelines encourage the creation of upstream forks, even in difficult cases such as https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#when-upstream-uses-prohibited-code, much less in order to forcibly upstream a trivial patch. In fact, it seems like such a fork would go against the spirit of https://fedoraproject.org/wiki/Staying_close_to_upstream_projects by obscuring the relationship of the packaged software to the “true” upstream. Certainly, the guidelines only advise that patches should be submitted upstream, and do not say that they must be accepted. In this case, https://docs.fedoraproject.org/en-US/packaging-guidelines/PatchUpstreamStatus/#_if_upstream_doesnt_have_a_bug_tracker would seem to apply. Similarly, https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text and the package review checklist require that upstream should be queried to include a separate license file when one is absent, but do not require that upstream accepts the suggestion. In both areas, I think the guidelines are entirely satisfied by my email to Greg Roelofs and by adding the appropriate comments to the spec file. > You can reuse %{name} and %{version} in the Patch0 line. I’m not sure about using %{version} here. I would expect the version in the patch should be the version against which the patch was created. If a future version 2.3.1 comes out, but the patch against 2.3.0 is still needed and applies cleanly without modification, then I would not expect the version number in the patch name to be updated. In the end, I think this is a matter of opinion rather than of Fedora policy, and opinions may validly differ. As a reasonable compromise, I have therefore incorporated the %{name} macro but removed the version number from the patch name altogether, i.e., %{name}-format-security.patch. > Also, please add a note above explaining why the patch is needed. That information needs to be in the SPEC file. Thanks; I have done so. > Should pngcheck-extras depend on pngcheck? If so, and it's very likely, … This is actually one of the rare cases where the dependency on the base package does not exist, either explicitly or implicitly. Each extra utility is a stand-alone executable built from a single C source file, and is perfectly useful without the pngcheck executable from the base package. The “extras” just happen to be released together with pngcheck in the same source tarball. (The -extras subpackage exists primarily to divide the binary RPMs by license, as advised in https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_multiple_licensing_scenarios, to avoid a multiple-licensed RPM.) > Since you're not using %make_install, please add the -p flag to your "install" calls to preserve timestamps. Good catch. I added -p for the file installations. (I can’t use %make_install because the upstream makefile lacks an install target.) ---- I think the above covers all of your review comments. Here are the updated URLs: Spec URL: https://gitlab.com/musicinmybrain/pngcheck-rpm/-/raw/master/pngcheck.spec Patch URL: https://gitlab.com/musicinmybrain/pngcheck-rpm/-/raw/master/pngcheck-format-security.patch SRPM URL: https://kojipkgs.fedoraproject.org//work/tasks/7401/53307401/pngcheck-2.3.0-1.fc34.src.rpm Koji build for Fedora 34: https://koji.fedoraproject.org/koji/taskinfo?taskID=53307375 Koji build for Fedora 33: https://koji.fedoraproject.org/koji/taskinfo?taskID=53307975 Koji build for Fedora 32: https://koji.fedoraproject.org/koji/taskinfo?taskID=53308374 Koji build for EPEL8: https://koji.fedoraproject.org/koji/taskinfo?taskID=53308440 Koji build for EPEL7: https://koji.fedoraproject.org/koji/taskinfo?taskID=53308517 -- 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
