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

Christoph Berg myon at debian.org
Mon Aug 18 10:34:21 UTC 2014


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.

> 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. The only time when
debian/control really changes is when postgresql-common changes the
set of "supported" PostgreSQL versions. There will be no surprises aka
FTBFSes unless when a transition is ongoing. The current transition
has been started weeks ago, and this is the first problem report, so
we can probably say the mechanism is working.

I am aware the situation isn't optimal. We have been thinking about
alternative approaches (like putting modules for all PostgreSQL
versions in a single binary package), but all of them involve
different disadvantages as well. Suggestions welcome :) (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.)

Christoph
-- 
cb at df7cb.de | http://www.df7cb.de/



More information about the Pkg-postgresql-public mailing list