https://bugzilla.redhat.com/show_bug.cgi?id=2262174
--- Comment #3 from Ben Beasley code@musicinmybrain.net --- 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.