On Tue, Aug 19, 2003 at 12:55:06AM +0100, Andrew Suffield wrote:
> On Mon, Aug 18, 2003 at 02:21:55PM -0600, Joel Baker wrote:
> > > 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.
>
> People seem to be doing quite well enough at catching those
> already. As you're so fond of saying, if they weren't then we wouldn't
> be having this conversation (note how meaningless that is?).
Primarily because a few individuals appear to be doing, on their own time
and bandwidth, exactly what I propose - that is, invoking the binary-indep
target on a building machine other than the maintainer's.
If they get hit by a bus, reassigned by their job to Outer Mongolia, or
just plain get bored with doing it, we lose that benefit entirely, as
things stand today. I'm proposing that the function appears to be producing
clear benefits, and that we should, in fact, adjust our expectations so
that we retain those benefits in a more direct fashion.
> > 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).
>
> Same thing applies to maintainer workstations.
No, in fact, it doesn't. Which is the crux of the question.
> > 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.
>
> Strange, I thought we actually managed to upload working packages most
> of the time. Are you attempting to suggest that we don't?
Are you attempting to suggest that the buildd arrangement uploads broken
packages more often than maintainers do?
Currently, the buildd structure appears (from the number of bugs filed,
and the number of emails that never hit the BTS) to be catching some
significant portion of the packages broken by maintainers. Toolchain errors
may not permit an otherwise valid package, but do not appear to cause
packages to become broken; in fact, fairly little I can see, other than
chroot contamination, could cause this. Which has been seen to happen, yes,
but only allows otherwise broken package (maintainer error) to continue to
propagate - *not* breaking packages themselves.
> > 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?
>
> Right back at you. You can swap "maintainer workstation" and "buildd"
> in your last mail and still have it about as meaningful, which should
> be a hint that you're pursuing a blind alley.
No, you can't. Or rather, you can swap it, and the wording is equally
parseable - but no longer accurate. See above.
> Note that it is much _more_ important for a maintainer workstation
> (where all the actually important stuff happens) to be working than it
> is for a buildd (which is largely automated, and thusly can be easily
> duplicated, replaced, or re-done).
Where a failed workstation means someone else can build it, upload it,
do an NMU; hell, you could even use the Debian machine farm (unless
the workstation is your only access at all, which is quite a different
question).
But this isn't actually relevant to the question of whether a buildd or a
maintainer machine is more likely to build a bad package (to wit, one which
cannot actually be rebuilt by $JOE_RANDOM from the distributed sources,
using a toolchain from the time the maintainer uploaded the package).
If you're going to assert that the buildds are breaking packages, please
provide some backing to the assertion; showing that maintainers break
packages is a trivial excercise in reading the BTS.
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpGJdnWoi2C4.pgp
Description: PGP signature