RFC: Page size on PPC/PPC64 builders

[Tom Lane]

David Woodhouse <dwmw2 at infradead.org> writes:
> I already see people who should know better complaining about how
> building for PPC is 'painful' -- and that kind of attitude has
> contributed to the idiocy of letting 'secondary architecture' builds
> fail _without_ aborting the main build. I don't want to make matters
> worse by increasing the perception that building for PPC is hard.

I've used many non-Intel arches for long enough to not particularly
worry about one versus another.  However, it took me darn near two
months to puzzle out the mysql bug that started this thread, and that
was way too painful.  The problems I see that we need to work on are:

1. It's impossible to reproduce the Koji build environment accurately
without access to PPC64 hardware; widely available stuff like Apple
Macs isn't PPC64 and won't show page-size-related problems.

2. There is pitifully little opportunity for Fedora developers to
get at such hardware.  As far as I've found out, there is exactly
one PPC64 machine available, its location is documented nowhere
public (eventually I found out that the magic incantation is "ask
David Woodhouse"), and it's down at the moment.

3. It was not at all obvious that the problem stemmed from changing
the build farm machines' underlying kernels from RHEL4 to RHEL5.
I wasted a great deal of time on the assumption that I was looking
for a consequence of a recent rawhide change, when in fact there was
no such change. 

Next time we make a change in the buildfarm's underlying kernels,
I respectfully suggest that that be treated as forcing a mass
rebuild, just like we do when there are other toolchain changes.
If I'd seen the breakage first occur in a context like that, it
would have been much clearer what to look for.

As for the other points, if we can't provide (and document) the
ability for developers to test on a secondary arch, that arch
needs to be removed from Fedora completely.  It's useless to
expect developers to magically fix things they can't debug.

			regards, tom lane