Neal Gompa wrote:
My instinct is that this wouldn't work, but I'm not certain.
Have you
tried this change with a scratch build? Scratch builds run the same
checks that normal builds do, and would be a good way to verify if
your theory is true.
%ifarch-ing noarch subpackages (note: noarch SUBpackages of arch-dependent
packages) actually works and does the right thing in Koji. (Koji will still
copy them to all the architectures, even if they were built only on one of
them.) As far as I know, this was implemented that way to make QEMU
firmwares work (which are built on and for a specific architecture, and then
shipped as noarch packages for all of them so that the architecture can be
emulated).
Back when we had secondary Koji instances, the secondary architecture people
used to complain about that practice because those noarch subpackages would
then be missing on their Koji instances. But now that we build alternative
architectures on the primary Koji, I do not see a good reason to not %ifarch
the noarch subpackages, at least in the cases where it works around a known
bogus comparison failure. (In the other cases, you may still want Koji to
actually do that comparison as a form of automated QA, even if it is
technically a waste of resources.)
Building, e.g., noarch documentation subpackages only on a fast architecture
such as x86_64 also helps speeding up builds on slower architectures such as
armv7hl, without actually affecting their users (as per the first
paragraph).
Kevin Kofler