Build system - why kill other arch builds?

[Dan Williams]

On Wed, 2005-08-10 at 14:18 -0600, Orion Poplawski wrote:
> It looks like when the build system encounters an error on one 
> architecture, it kills the builds on the other archs.  What is the 
> reason for this?  I would find it helpful to know if the build would 
> have succeeded on the other architectures.

If you've got an error on one arch, then you have to respin the package
anyway.  It forces you to fix the error and not ignore the arch that
failed.

If you, as the maintainer, only have access to an i386 box, and your
build would have failed on both ppc and x86_64 (which you don't have
access to), there's no guarantee that the failure is the same, and there
is no guarantee that your fix will even work on either architecture
since you have no access to them anyway.  I don't think it's necessarily
a win to allow other arches to proceed when one fails, since (a) you
can't know your fix will work on PPC, (b) you can't know your fix will
work on x86_64, even if it works on PPC, (c) there may be some further
error one arch.  If you don't have access to an arch, you cannot get
away from the song and dance of "try it and see if it fails."

Now this could also be fixed by something like the "scratch" targets
that we were talking about earlier, where this policy _could_ be
implemented.  "scratch" targets would not feed into the repository, but
their base packages would be pulled from it.  Therefore, you could test
your packages without having them interfere with the repo, or with the
"official" build queue.  When you are more or less certain that your
packages build, you can submit them to the "official" queue. 

Dan