Re: Ansgar Burchardt 2014-08-18 <53f1cbb6.8080...@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 -- c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
