On Sat, 2007-06-16 at 14:08 +0200, Ralf Ertzinger wrote: > On Fri, 15 Jun 2007 12:38:28 +0100, David Woodhouse wrote > > You're right -- as things stand, we do need a team of folks who can > > help out with basic issues where the packager can't cope. It usually > > isn't arch-specific; very little really is when you get down to it. > > Arch specific in the sense of "this does not work on PPC": yes, I can > agree with that. That's what I meant, yes. > Arch specific in the sense of "does work on i386 and nowhere else": > it seems to me that there is quite an amount of C code that assumes > that an int is 32 bit and the world is little endian. Code written _that_ badly is rarely good enough to be shipped with the 'Fedora' label on it anyway, for a variety of reasons. It's also a case which I was mostly ignoring as uninteresting in this context, since it's the "needs porting" case which just gets a one-off ExcludeArch; either when the package is first imported or when the arch team build all packages for their arch before applying to become a Secondary Architecture. It hardly takes any effort for the package owner at all; certainly not any recurring effort. The _important_ case we have to care about is when a package _used_ to build and suddenly doesn't. I think that's the one that people are concerned about. Perhaps because they haven't actually looked at the data and didn't realise that a significant proportion (and probably even the _majority_) of such failures aren't actually arch-specific bugs at all, when you get down to the root of it. And even the failures which _are_ arch-specific can easily be handled with a retrospective ExcludeArch and the 'ship it anyway' button. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
