For header-only library packages, this change would make it explicit that only the base package is required to be arched, while explicitly allowing any or all subpackages to be noarch. This provides the same benefits stated in the current guidelines as justification for a general prohibition on noarch:
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” from the subpackage)
However, for many header-only libraries, the header files are actually architecture-independent, and nothing is installed into an architecture-dependent path such as %{_libdir}. In these cases, marking subpackages, such as the -devel subpackage, noarch makes sense. Since header library packages typically have no %files section for the base package, a typical result would be a package that is built “arch-fully” but produces noarch 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
For header-only library packages, this change would make it explicit that only the base package is required to be arched, while explicitly allowing any or all subpackages to be noarch. This provides the same benefits stated in the current guidelines as justification for a general prohibition on
noarch:However, for many header-only libraries, the header files are actually architecture-independent, and nothing is installed into an architecture-dependent path such as
%{_libdir}. In these cases, marking subpackages, such as the-develsubpackage, noarch makes sense. Since header library packages typically have no%filessection for the base package, a typical result would be a package that is built “arch-fully” but produces noarch rpms. This would:This change was initially raised on the packaging mailing list.