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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
