Heads up: Noarch Subpackages

[Panu Matilainen]

On Fri, 13 Feb 2009, 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].

Slight correction: checking for binaries in noarch packages is related but 
different than the rpm < 4.6 issue: rpm 4.4.x does funny things when 
sub-packages try to declare themselves as noarch, and that needs an 
entirely different fix (fail the build right at the start which it 
should've always done).

 	- Panu -