Re: Binaryless uploads [Was: FTBFS: architecture all packages]
Andrew Suffield <asuffield@debian.org> writes:
> On Sun, Aug 17, 2003 at 09:38:54PM -0500, Joe Wreschnig wrote:
> > On Sun, 2003-08-17 at 20:57, Andrew Suffield wrote:
> > > Secondly, in the current system, if it "doesn't build", then the
> > > maintainer would not be able to upload the package at all, because
> > > their build of it would fail. Source-only uploads would _remove_ this
> > > check, thereby making FTBFS issues more common. They certainly
> > > wouldn't prevent any problems that currently happen.
> > >
> > > Thirdly, this idea demonstrates a lack of understanding of what causes
> > > FTBFS bugs. It is emphatically _not_ the case that every package can
> > > be categorised as "does build" or "doesn't build".
> >
> > What causes FTBFS bugs now:
> > 1. Bad Build-Depends.
>
> These are handled by the current system - they're trapped on the buildd.
Unless the bug only appears on the arch the maintainer provides
binaries for (which means never for binary-all). And even if its
detected the uploaded binary still makes it to sid.
One can argue that thats what sid is for but for binary-all there is
nothing stopping the bogus deb to enter testing and stable unless
someone manually treis to rebuild it.
> > 2. Broken code that doesn't port (either to another architecture, to
> > something that's not the maintainer's home directory, whatever).
>
> And so are these.
Again not for binary-all since they are never build by buildds.
> > All of 1 and many of 2 would be solved by binaryless uploads. A new
> > type, "maintainer never tried to build package ever (and so debian/rules
> > has a syntax error or debian/control has a bad version or whatever)"
> > would be introduced - but such packages would be blocked from entering
> > the archive anyway.
>
> But none of this is new. These things are already handled by the
> system we currently have in place.
Only mostly.
> What you are proposing to do is essentially to require that a package
> has built on all architectures before installing it into the
> archive. We have that already: it's called "testing".
One could propose that (binary-all) packages must be build by at least
one buildd [and could be build (and thrown away) by any idle buildd].
As you say binary-any packages will be build by buildds for the other
archs. Its unlikely that a maintainer will go through all the trouble
of manually building for all archs for an upload, but it would be
possible.
MfG
Goswin
Reply to: