For your consideration: Secondary Architectures in Fedora

[David Woodhouse]

On Tue, 2007-06-12 at 15:57 -0400, Christopher Blizzard wrote:
> I've been talking to people on and off about this and I think you're
> statement elsewhere in this thread hit it right on the nose: it's good
> to have a nice mix of 32 and 64 bit as well as LE and BE systems.  So I
> think it's important that PPC be a primary arch and package maintainers
> are responsible to make sure that it works before any builds are pushed
> out to the repos.

Yes, it certainly makes a lot of sense. Including something with
signed-char and something with unsigned-char is good, too.

> PPC is the fastest canary in the cage, if you will. :)

Having looked over the FE-ExcludeArch-ppc tracker, I think 'canary' is a
good word. When it falls over, you really don't want to ignore it.

If you ignore the trivial 'Needs Porting' bugs and the 'IBM made us
break it' bugs (caused by stuff like 128-bit long double and 64KiB pages
on PPC64), and look at the remaining cases where the package _used_ to
build and then suddenly failed.... you find that a _significant_
proportion of them are actually _generic_ problems where PPC just
happened to fall over first, rather than really being a PPC-specific
problem. In fact, it may even be the majority. Examples...

Bug 201739: Macaulay2: ppc build hangs, never finishes
 - showed up a generic 32-on-64 kernel bug affecting x86_64 too (220892)

Bug 193727: Build on ppc fails some tests during the %check phase
 - timing-related differences causing 'make check' to fail
 - a harder failure caused by aliasing, not arch-specific.

Bug 189160: internal compiler error: in get_callee_fndecl, at tree.c:5846
 - compiler bug not arch-specific, I believe. GCC PR #27134?

When a package _used_ to build but no longer does, that is _often_ an
indication of a generic problem rather than an arch-specific problem --
which is why I think 'canary' was such a good choice of word on your
part. It really shouldn't go uninvestigated.

In particular, if a package builds on some architectures but
unexpectedly fails on others, I think it would be very unwise to
automatically ship it on the architectures for which it happened to
build.

Have a 'ship it anyway' button for the maintainer to use after they've
at least _looked_ at the failure and found it to be harmless, by all
means. But don't just let a partially-failed package get shipped
automatically. Really.
 
-- 
dwmw2