https://bugzilla.redhat.com/show_bug.cgi?id=2262174 --- Comment #3 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- Thank you for the review! > a) Logo is CC0 https://github.com/pgjones/hypercorn/blob/main/artwork/LICENSE but does not seem to be packaged. That was my conclusion as well. If it were packaged, it would be OK (CC0-1.0 allowed for content, not for code) but it would need to appear in the License expression. > b) License file is packaged twice at: > /usr/share/licenses/python3-hypercorn/LICENSE > /usr/lib/python3.12/site-packages/hypercorn-0.16.0.dist-info/LICENSE > > but seems incorrectly marked: > rpm -qL python3-hypercorn-0.16.0-1.fc40.noarch.rpm > /usr/share/licenses/python3-hypercorn/LICENSE This is typical of packages using poetry (using poetry-core as the build backend). From https://src.fedoraproject.org/rpms/pyproject-rpm-macros: %pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-File field are detected. PEP 639 is still a draft and can be changed in the future. Since Poetry doesn’t implement the draft PEP 639, %pyproject_save_files isn’t able to mark license files in .dist-info directories with %license when the package is built with poetry-core as the build backend. It’s correct that Poetry packages these files in .dist-info (to ensure they are distributed with wheels), and it’s valid that they choose not to implement a draft PEP, even though many other Python build backends do implement it. In order to mark the license file in .dist-info manually, we would need to sed-patch the file at %{pyproject_files}, which is feasible, but kind of ugly for the small improvement it would bring, and is needlessly different from the “usual practice” for Python packages built with poetry-core. Besides, we still couldn’t use %pyproject_save_files -l, and so there would be a risk of accidentally dropping the license file altogether in an update if we omitted the manual %license LICENSE. It’s better to accept a duplicate copy of the license file in exchange for simplicity and a guarantee that *at least one copy* is properly marked. > c) Will the subpackages always pull in the main package? Yes, the subpackages python3-hypercorn+h3, python3-hypercorn+trio, and python3-hypercorn+uvloop always have a fully-versioned dependency on python3-hypercorn. If they did not, it would represent a bug in the implementation of the %pyproject_extras_subpkg macro that was used to define them. Since they’re metapackages with no file contents of their own, the fact that they have a License field matching that of the base package is pretty much just a formality anyway. -- 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=2262174 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202262174%23c3 -- _______________________________________________ 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
