Make ppc64 secondary arch - don't block builds (was: Dealing with ppc64 BRs)

[David Woodhouse]

On Tue, 2007-08-07 at 01:48 -0400, Tom Lane wrote:
> Again: this is a matter of trying to bring Extras up to a portability
> standard we have long held Core to.  I have little respect for any
> Extras-package maintainer who won't at least try to meet the
> challenge.
> If you're stuck because you depend on some other package that doesn't
> build on ppc64, then of course it's not your fault --- but if *you*
> are the roadblock, it's time to pull the socks up. 

I think that's perhaps a little harsh in some cases. Take the blocker in
Ralf's case, for example -- ocaml. I wouldn't necessarily expect a
package maintainer to be willing and able to port its code generation
back end to any new architecture which we happen to add to Fedora; that
really is the job of the 'arch team'.

(I am inclined to agree with you in the cases where the build failure is
something simpler like stupid assumptions about wordsize, char
signedness, endianness, etc. -- but there are extremely vocal Fedora
contributors who disagree even with that, and who believe that it's
acceptable for a packager to be responsible for a package even if they
don't understand the language it's written in, and are completely
incapable of dealing with or even _understanding_ any bugs in it.
Quantity, not quality, is the apparent motivation.)

For architectures which are newly added to Fedora's build system, I
don't think it's reasonable to expect package maintainers to handle the
_first_ build of their package on that architecture. The arch team
responsible for the new arch should attempt to build all packages in
advance, and each package should either have an ExcludeArch filed or a
binary package present in the builder's repository before the big switch
is flipped to incorporate that arch into the build system.

We should probably consider PPC64 to be a 'new arch' for Extras
packages, because we never built Extras for PPC64 before. So it's
acceptable for people to just file an ExcludeArch if they build their
package for the first time since the merge and it fails on PPC64. Most
of our packagers are conscientious enough to take a look and see if it's
something they can fix. Some are even insane enough to embark upon real
porting work (and I'm happy to give them accounts). But I don't think
it's reasonable to _expect_ them to go that far for a new architecture.

Once the package in question is known to have been OK on a given
architecture and if it _later_ starts to fail, that's something we'd
expect the package maintainer to at least glance at. But not the _first_
build on the architecture in question.

-- 
dwmw2