Currently, the packaging guidelines say the following[1] regarding header-only libraries:
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 marked noarch.
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[2], 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 packages
I have created a PR[3] 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[4] with specific proposed text.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_do_not_use_noarc... [2] https://docs.pagure.org/koji/misc/#how-noarch-sub-packages-are-built [3] https://src.fedoraproject.org/rpms/atomic-queue/pull-request/1 [4] https://fedoraproject.org/wiki/Packaging_Committee#Step_One:_Draft_Guideline...
On 09. 12. 21 15:03, Ben Beasley wrote:
Currently, the packaging guidelines say the following[1] regarding header-only libraries:
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 marked noarch.
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[2], 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 packages
I have created a PR[3] 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[4] with specific proposed text.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_do_not_use_noarc... [2] https://docs.pagure.org/koji/misc/#how-noarch-sub-packages-are-built [3] https://src.fedoraproject.org/rpms/atomic-queue/pull-request/1 [4] https://fedoraproject.org/wiki/Packaging_Committee#Step_One:_Draft_Guideline...
I like this, but it should mention that this is not always possible. Some header-only libraries install stuff to %{_libdir} (e.g. cmake files or pkgconfig).
I like this, but it should mention that this is not always possible. Some header-only libraries install stuff to %{_libdir} (e.g. cmake files or pkgconfig).
You’re right. Considering this, “many” header-only library packages could benefit, rather than “the vast majority.”
Of the twelve header-only libraries for which I am primary maintainer (atomic-queue, debugbreak, dr_libs, earcut-hpp, fast_float, geompp, gulrak-filesystem, hedley, lexertl14, pcg-cpp, stb, wyhash), nine look like they could benefit from this technique, and the remaining three could not because they install CMake files to %{_libdir}/cmake.
* Ben Beasley:
Of the twelve header-only libraries for which I am primary maintainer (atomic-queue, debugbreak, dr_libs, earcut-hpp, fast_float, geompp, gulrak-filesystem, hedley, lexertl14, pcg-cpp, stb, wyhash), nine look like they could benefit from this technique, and the remaining three could not because they install CMake files to %{_libdir}/cmake.
Can we teach cmake to look under %{_datarootdir}/cmake as well?
Thanks, Florian
On 12/9/21 09:43, Florian Weimer wrote:
Can we teach cmake to look under %{_datarootdir}/cmake as well?
Thanks, Florian
I think that this will work already in at least some cases [1]. Some packages are already installing .cmake files to %{_datadir}/cmake/<name>, %{_datadir}/<name>/cmake, or similar.
It may be that patching CMakeLists.txt to adjust the install path for these files, or applying “mv” after %cmake_install, could be a reasonable choice for some header-only library packages that have arch-independent .cmake files installed at an arch-dependent path. I don’t know CMake’s many special cases well enough to say whether or not this is always safe to do.
– Ben
[1] https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-se...
Am Donnerstag, dem 09.12.2021 um 15:43 +0100 schrieb Florian Weimer:
- Ben Beasley:
Of the twelve header-only libraries for which I am primary maintainer (atomic-queue, debugbreak, dr_libs, earcut-hpp, fast_float, geompp, gulrak-filesystem, hedley, lexertl14, pcg-cpp, stb, wyhash), nine look like they could benefit from this technique, and the remaining three could not because they install CMake files to %{_libdir}/cmake.
Can we teach cmake to look under %{_datarootdir}/cmake as well?
CMake already does that, as long as the path is %{_datarootdir}/cmake/${pkg_name} and the dir contains valid .cmake files.
Björn aka besser82
On Thu, Dec 9, 2021 at 3:33 PM Ben Beasley code@musicinmybrain.net wrote:
(snip)
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[2], 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 packages
I have created a PR[3] 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[4] with specific proposed text.
I think making the *subpackages* noarch is a good idea, if that's possible.
In fact, that's how Rust packages already work (well, they're not "header-only", but "source-only", but the difference doesn't matter here ...) We run a test build and run tests on all supported architectures, but ship sources as noarch -devel subpackages.
Fabio
I have submitted a Packaging Draft:
https://pagure.io/packaging-committee/pull-request/1140 https://pagure.io/packaging-committee/issue/1141
On 12/9/21 09:03, Ben Beasley wrote:
Currently, the packaging guidelines say the following[1] regarding header-only libraries:
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 marked noarch.
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[2], 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 packages
I have created a PR[3] 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[4] with specific proposed text.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_do_not_use_noarc...
[2] https://docs.pagure.org/koji/misc/#how-noarch-sub-packages-are-built [3] https://src.fedoraproject.org/rpms/atomic-queue/pull-request/1 [4] https://fedoraproject.org/wiki/Packaging_Committee#Step_One:_Draft_Guideline...
packaging@lists.fedoraproject.org
-
Ben Beasley -
Björn 'besser82' Esser -
Fabio Valentini -
Florian Weimer -
Miro Hrončok