Heads up: Noarch Subpackages

Panu Matilainen pmatilai at laiskiainen.org
Fri Feb 13 13:48:27 UTC 2009


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 -




More information about the fedora-devel-list mailing list