Heads up: Noarch Subpackages

[Ralf Corsepius]

Panu Matilainen wrote:
> 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.
So you don't destinguish between native and foreign?
This would be a serious deficiency.

>> [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.
Non applicable.

cross-tool packages typically contains binaries from several different 
architectures.

> 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.
Making these
a) PATH-aware (e.g. according to FHS rules)
b) very restrictive on destinguishing "native" vs. "foreign"
is the only solution I am aware about.

(actually, a) is sufficient)

>>> 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.
Your corner case is my standard use-case. Your "sanity check", from my 
POV doesn't actually belong into rpm but into some external tool.

Ralf