Re: Why not to let all DDs to execute "gb"-command

[Goswin von Brederlow <goswin-v-b@web.de>]

On Tue, Jun 11, 2013 at 09:15:48AM +0800, Chow Loong Jin wrote:
> On Mon, Jun 10, 2013 at 10:43:57PM +0200, Philipp Kern wrote:
> > Hi,
> > 
> > On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote:
> > > So, I think the developer should have a set of tools (including gb and
> > > even "slight" removal commands), which allow him to do the most of
> > > packaging work without worrying other teams/developers. And, of course,
> > > those tools should be relatively secure not to break others work and the
> > > whole archive. "gb" is a harmless in this case.
> > 
> > it is not. If you rely on random successes of your build this is worse than not
> > providing a build at all. If there's a security issue, people will be forced to
> > spend time on the issue. Either the Security Team or by extension the Stable
> > Release Team, to get it built to finally include it into a point release or
> > leave it lingering forever in p-u-new because a test case fails.
> 
> It's not always the case of relying on random successes of your build. There are
> valid cases -- for example, if a build-dep, or a dep of a build-dep had a bug
> that prevented installation, and has just been fixed.
> 
> -- 
> Kind regards,
> Loong Jin

I wonder if in that case it wouldn't make more sense to allow setting
an additional Build-Depends / Build-Conflicts instead of give-back
once the problematic deb was fixed.

So instead of:

- wait for problem to be fixed or foobar to be build on that arch
- gb package

you would do:

- extra-build-hint --conflicts foobar 1.2-3
[
- wait for foobar to get fixed or newer foobar to be build on that arch
- watch the buildd retry your package automatically
- throw a party
]

MfG
	Goswin

PS: replace extra-build-hint with whatever wb command does this