Heads up: Noarch Subpackages

[Panu Matilainen]

On Fri, 13 Feb 2009, Ralf Corsepius wrote:

> Panu Matilainen wrote:
>> On Fri, 13 Feb 2009, Michael DeHaan wrote:
>> 
>>> Florian Festi wrote:
>>>> Ville Skyttä wrote:
>
>>>> As another solution for this problem we (ehm, Panu) will backport a check 
>>>> that will make noarch packages (both regular and noarch) fail to build if 
>>>> they contain binaries (==colored files==the right thing to do even for 
>>>> emulators, bioses, cross compilers, ...[1]). This additional check will 
>>>> be in place before koji will be updated [2].
>
>>> I would prefer that, at least, there was a way to bypass this binary file 
>>> check in the specfile for apps that have a legitimate reason to do it.
>> 
>> Yes, there's an override, precisely for these kind of reasons:
>> 
>> # Should binaries in noarch packages terminate a build?
>> %_binaries_in_noarch_packages_terminate_build   1
>> 
>> Turning that off in spec will make binaries in noarch packages
> How is "binary" defined?

Currently it's only ELF executables and DSO's.

> [Related to it: The current definition as being used by the debug-info 
> generation/build-id checks in Fedora's rpm are a PITA when it comes to 
> packaging cross-tools/cross-libraries]

You'd need to have debugedit and various other pieces available for the 
cross target and setup rpmbuild to use those instead of the native ones 
when cross-building. Should mostly be possible even as it is, but most 
likely find-debuginfo.sh and friends could use some further 
parametrization to make it easier to do. Or just disable the 
debuginfo/build-id & friends for cross-tools/libraries.

>> a warning, and it serves as documentation "yes we're doing something a bit 
>> special, this is intentional" too.
> Why does this check + warning exit all?
>
> IMO, by marking a package/sub-package "noarch" the package's author has 
> clearly noted his intentions to be wanting the arch to be ignored. Of cause 
> this carries a risk of accidentally packaging native binaries into   supposed 
> to be "noarch" packages, but these can pretty easily be distinguished from 
> "foreign binaries" by other means (e.g. by restricting such checks to certain 
> PATHs).

It's just a packaging sanity check, just like unpackaged / missing files 
and such. Noarch package carrying arch-dependent binaries is a pretty 
grave package error except for some corner cases such as where the 
binaries are carried as "content", not something to execute on the host.

 	- Panu -