Heads up: Noarch Subpackages

[Michael DeHaan]

Panu Matilainen wrote:
> On Fri, 13 Feb 2009, Michael DeHaan wrote:
>
>> Florian Festi wrote:
>>> Ville Skyttä wrote:
>>>> Regarding policy changes, one candidate for addition would be that 
>>>> if a non-noarch package does noarch subpackages, it MUST 
>>>> BuildRequire rpm-build >= 4.6.0.  Or if there's a way to wrap the 
>>>> "BuildArch: noarch" for subpackages in a %if $something ... %endif 
>>>> where $something evaluates to true only in rpmbuild versions 
>>>> supporting these noarch subpackages, that'd be ok too.  This is 
>>>> because if such a package is built with an earlier rpmbuild 
>>>> version, the build can succeed but not only the one expected 
>>>> subpackage will be noarch, but so will/may be the main package and 
>>>> all other subpackages as well.  These builds often fail because of 
>>>> invalid options ending up passed to ./configure or debuginfo 
>>>> extracted but not packaged, but there are scenarios where the build 
>>>> doesn't fail and chaos ensues.
>>>
>>> I agree that this is a problem. But I very much dislike putting 
>>> BuildRequires to rpm versions into spec files. If we start with that 
>>> every package will have them very soon. We - RPM upstream - are 
>>> already working on the next improvements for rpmbuild that would 
>>> also lead to such BuildRequires. Even worse is that they will get 
>>> outdated easily and unnoticed - as they are only being some last 
>>> line of defence - and though be useless when they are really needed.
>>>
>>> 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'm a bit confused by this change.  In my case, cobbler embeds a copy 
>> of elilo because we want to be able to make an install server that 
>> runs on x86/x86_64/other that also can install ia64/ppc/etc.   Same 
>> for syslinux, etc -- you may want to run an install server on ia64 
>> that serves up x86/x86_64 content.  Thus this content is stuff we 
>> need to /serve up/ rather than content we need to run on that 
>> host.    I /think/ that's why I'm CC'd on this.
>>
>> It would be great if those packages themselves (syslinux) could have 
>> noarch portions, so any package could carry them as a payload.
>>
>> The alternative is asking the user to find this content themselves, 
>> and right now it's not possible to install elilo on a x86 system with 
>> yum, which makes it quite confusing on them.
>>
>> 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 a 
> warning, and it serves as documentation "yes we're doing something a 
> bit special, this is intentional" too.
>
>     - Panu -

Outstanding, do I have to if around which builds pass that flag/macro?  
(i.e. would an EPEL 4 build (or an older rpmbuild) understand that?)

--Michael