[Pkg-postgresql-public] Bug#758482: Bug#758482: Bug#758482: Bug#758482: pg-reorg: builds packages not listed in source package's debian/control

Ansgar Burchardt ansgar at debian.org
Mon Aug 18 10:44:06 UTC 2014


On 08/18/2014 12:34, Christoph Berg wrote:
> Re: Ansgar Burchardt 2014-08-18 <53F1CBB6.8080602 at debian.org>
>> So it's a case of should never break in theory, but does in practice? :)
> 
> Not quite. You just found the single package which wasn't updated for
> 9.4 yet, because it's broken upstream. There was no RC bug about it
> yet because I had it on my radar.

i.e. it breaks.

>> Please don't silently regenerate d/control. It could generate a new one
>> and *fail* the build if it differs; the maintainer should use a special
>> target in d/rules or "mv d/control.new d/control" and restart the build.
> 
> We rely on that mechanism to make backports and builds for
> apt.postgresql.org to automatically create the right set of binaries.
> 
> Note that the regeneration of debian/control should only happen on
> "clean" which I believe the buildds do not invoke.

Except that pg-reorg started to build packages not listed in d/control
on buildds... Which lead me to write a bug report.

https://buildd.debian.org/status/fetch.php?pkg=pg-reorg&arch=s390x&ver=1.1.9-2%2Bb1&stamp=1408310111

> The current transition
> has been started weeks ago, and this is the first problem report, so
> we can probably say the mechanism is working.

It works unless packages are built at a different time than you expect,
like binNMUs for other reasons. That's what I mean by "works in theory,
but breaks in practice".

> (Note that
> with the current system, having to manually confirm the control update
> would just have traded one kind of FTBFS for another kind, which I
> wouldn't see as a change in the right direction.)

It would at least FTBFS on the buildd and not upload broken things to
the archive.

Ansgar



More information about the Pkg-postgresql-public mailing list