Heads up: Noarch Subpackages

Panu Matilainen pmatilai at laiskiainen.org
Sat Feb 14 08:15:51 UTC 2009


On Fri, 13 Feb 2009, Michael DeHaan wrote:

> 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?)

No need to work around it for older rpm versions: it's just another macro 
definition, not a new spec keyword.

 	- Panu -




More information about the fedora-devel-list mailing list