Re: update on binary upload restrictions
On Mon, Jan 29, 2007 at 10:42:25AM +0100, Goswin von Brederlow wrote:
> Santiago Vila <sanvila@unex.es> writes:
> > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote:
> >
> >> If we do go to source-only uploads, could this problem be avoided by
> >> having arm and other slow arches wait until at least one other arch
> >> successfully builds the package?
> >
> > I think that would be a good idea anyway, even if we do not go to
> > source-only uploads. There is no point in wasting expensive CPU cycles
> > to build a package if it FTBFS on every architecture.
>
> I would rather do the opposite. Stop building a package when it fails
> on other archs.
How many other architectures. One? All of them?
Imagine something breaks R on m68k (which, by a string of total
coincidence, just happens to be true at this point in time), and then
someone uploads a new R package, which obviously fails to build there.
Should all other architectures refuse to build it now, just because that
package was new and thus not yet marked as "don't build this on m68k
until that R bug is fixed"? Stop building a package when it fails on one
other arch is not really an option.
Stop building when it fails on all other architectures? That kinda
defeats the purpose, because then only *one* other architecture will be
able to spare CPU cycles.
I don't think it's a bad idea to add upload date to the order in which
packages are built; that would allow slow architectures to chicken out
on the upload frenzy of a silly maintainer. But other than that...
Besides, the way wanna-build is implemented, it's impossible to use the
state of a package in *another* architecture as a parameter for
anything without resorting to the ugliest hacks one can come up with.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: