I’m aware that pyproject-rpm-macros can handle license files in many
> %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-Field field are detected. PEP 639 is still a draft and can be changed in the future.
(I also know that there are some packages where no license file is
marked, or where additional license files are needed, and it’s best to
verify with “rpm -qL -p …” before relying on this feature. That’s not at
In a package review, it was suggested that, even when pyproject_files
includes a license file installed in the dist-info directory and marked
with %license, an explicit installation of the license file with a
relative path, such as
> %license LICENSE.txt
might still be needed—under the theory that the license file is supposed
to be installed in /usr/share/licenses.
The Licensing Guidelines simply say that %license must be used, and
don’t mention /usr/share/licenses.
I’m wondering if this question has come up before and if anyone has
insight into whether or not pyproject-rpm-macros’s license file support
is intended to replace manual license file handling.
– Ben Beasley
Currently, the packaging guidelines say the following regarding
Do not use noarch
It may be tempting to make the header library package noarch, since
the header files themselves are simply text. However, a library should
have tests which should be run on all architectures. Also, the install
process may modify the installed headers depending on the build
architecture. For these reasons, header-only packages must not be
I’d like to collect feedback on the idea of revising this guidance to
clarify that the *base* package, which in a header-only library package
typically has no %files section and does not produce a binary RPM, must
be arched, but that any subpackages, specifically including the -devel
package, may be noarch.
This would address both of the justifications for the general
prohibition in the guidelines:
- The package will still be built, and any tests executed, on all
architectures so long as the base package is not noarch
- Differences in the installed headers depending on the build
architecture would be detected by koji, failing the build
(and thereby indicating the need to drop “noarch”)
However, it would confer the following benefits:
- The vast majority of header-only packages could produce noarch
binary rpms. This would:
* save storage and bandwidth
* be less surprising and confusing to packagers and users, who
normally expect arch-independent content to appear in noarch
I have created a PR on the “atomic-queue” package as an example. In
the associated scratch build, you can see that builds occur on all
architectures, but only a single noarch RPM is produced.
If feedback here is positive, I’ll open a Packaging Draft with
specific proposed text.