Heads up: Noarch Subpackages

Michael DeHaan mdehaan at redhat.com
Fri Feb 13 13:25:16 UTC 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].


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.

While the content is architecture specific, the content is not destined 
for the server on which it is installed, and absolutely needs to be 
there for the install server to work for those other arches.

I'd rather err on the side on making things more inclusive of secondary 
arches in this case rather than making it harder to deploy those platforms.

--Michael




>
> Florian
>
> [1] This assumes that those packages are build correctly and do not 
> leave the foreign binaries executable after %install and though avoid 
> that they get picked up by the automatic dependency generator and get 
> listed as colored.
>
> [2] Special greeting to the owners of alsa-firmware, avr-libc, 
> cobbler, taskcoach and texlive-texmf-doc




More information about the fedora-devel-list mailing list