Re: Why not to let all DDs to execute "gb"-command
- To: debian-devel@lists.debian.org
- Subject: Re: Why not to let all DDs to execute "gb"-command
- From: Goswin von Brederlow <goswin-v-b@web.de>
- Date: Thu, 18 Jul 2013 15:03:03 +0200
- Message-id: <[🔎] 20130718130303.GF23957@frosties>
- In-reply-to: <20130611011546.GA20299@gmail.com>
- References: <51AF8D2F.6070203@debian.org> <20130609184458.GA1089@roeckx.be> <51B61348.2000902@debian.org> <20130610204357.GA17941@simplex.0x539.de> <20130611011546.GA20299@gmail.com>
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
Reply to: