PR#1140: Explicitly permit noarch subpackages for header-only libraries - packaging-committee

packaging-committee

#1140 Explicitly permit noarch subpackages for header-only libraries

Merged 2 years ago by tibbs. Opened 2 years ago by music.

music/packaging-committee header-only-noarch into master

Explicitly permit noarch subpackages for header-only libraries

Benjamin A. Beasley • 2 years ago

02adc25

guidelines/modules/ROOT/pages/index.adoc

file modified

+11 -8

		`@@ -1607,14 +1607,17 @@`
		Packages which use the header library must `+BuildRequire: foo-static+`,
		`so that the usage can be tracked.`

		`- ==== 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.`
		`+ ==== Use noarch only in subpackages`
		`+`
		`+ The base package for a header library MUST NOT be marked noarch.`
		`+ This ensures that any tests are run on all architectures,`
		`+ and makes it possible to detect whether the build or install process`
		`+ has modified the headers based on the build architecture.`
		`+`
		+ When the contents of subpackages, including the `+-devel+` package,
		`+ are actually architecture-independent, they may still be marked noarch.`
		+ Since the base package for a header library typically has no `+%files+` list,
		`+ this may result in an arched package that builds only noarch rpms.`

		`=== Statically Linking Executables`

music commented 2 years ago

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

This change was initially raised on the packaging mailing list.