[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Heads up: Noarch Subpackages



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]