Revisiting header-only packages and noarch

[Ben Beasley]

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_no...
[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_Guidel...

[Miro Hrončok]

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_no...
>  [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_Guidel... 
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).

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Ben Beasley]

>  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.

[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?

Thanks,
Florian

[Ben Beasley]

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...

[Björn 'besser82' Esser]

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

[Fabio Valentini]

On Thu, Dec 9, 2021 at 3:33 PM Ben Beasley <code(a)musicinmybrain.net&gt; 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

[Ben Beasley]

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_no... 
> 
> [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_Guidel... 
>