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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130718130303.GF23957@frosties
