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