Re: Heads up: Noarch Subpackages

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

 



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

--Michael



--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux