[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Binaryless uploads [Was: FTBFS: architecture all packages]



On Mon, Aug 18, 2003 at 06:08:16PM +0100, Andrew Suffield wrote:
> On Mon, Aug 18, 2003 at 10:04:49AM -0600, Joel Baker wrote:
> > So, in the interest of proposing a (hopefully) useful alternative, which
> > doesn't cause 11 buildd failures because of a flat-out binary-less upload
> > policy:
> > 
> > [ Proposal - capitalized words should be considered to have RFC-style     ]
> > [ meanings, because I want to be clear and I'm sure this would be         ]
> > [ rewritten before going into any actual policy.                          ]
> > 
> > Uploads to the archive MAY contain compiled package files for any of the
> > currently supported architectures; they SHOULD (MUST?) contain at least one
> > full set of architecture-specific package files.
> > 
> > Uploads MUST NOT contain architecture-independant package files; for
> > each upload, one build daemon will be selected to build and upload the
> > architecture-independant packages, in the same general manner as building
> > the architecture-dependant packages for architectures which were not
> > uploaded (this is not guaranteed to occur on the same run as a build of any
> > architecture-dependant packages; it is not even guaranteed to occur on the
> > same build daemon).
> > 
> > [ End ]
> 
> This is based on the assumption that a given buildd has a better
> chance of being "valid" than the maintainer's workstation. I see no
> reason to believe that.

No, it is based on the assumption that a buildd will only install things
listed in the Build-Depends, which means it will catch stuff that only
builds on the maintainers workstation because they aren't building
inside a chroot and are being sloppy - one of the main things they catch
for binary-arch targets, today.

In fact, the buildd is presumed to be valid - must be - because we're
using it for every architecture not uploaded. Invalid buildds are, as
far as I have observed, caught fairly rapidly, and taken out of the pool
until fixed (barring toolchain failures which only affect a few
packages, or the like).

A maintainer's workstation cannot be presumed to be valid, because we
regularly demonstrate that this isn't the case. If we could presume it
was valid, we wouldn't be having this conversation at all.

Thus, the maintainers workstation is (almost) never *more* likely to be
valid, and experience indicates that it is, in fact, quite a bit less
likely to be valid.

If you think the buildds are invalid, perhaps you should take the matter up
with the people running them, and so they can try to fix whatever problems
you are seeing?
-- 
Joel Baker <fenton@debian.org>                                        ,''`.
Debian GNU NetBSD/i386 porter                                        : :' :
                                                                     `. `'
				                                       `-

Attachment: pgp3d0jqDYCMc.pgp
Description: PGP signature


Reply to: