[Pkg-postgresql-public] Dropping postgresql 8.3 for squeeze
dfontaine at hi-media.com
Wed Jan 6 20:13:45 UTC 2010
Stephen Frost <sfrost at snowman.net> writes:
> To be honest, some of the other comments made previously about having a
> postgresql-dev-common package are reasonable concerns. To try and sum
> up the concern, if we have a postgresql-dev-common with server versions
> or even a postgresql-server-dev-common and Martin maintains it, then
> when he uploads a new major PG version we could end up with a bunch of
> broken packages.
That's not true with what I'm currently proposing.
> Consider the PG change to require magic cookies which happened a couple
> releases ago. That's an API-level change which would break every
> module. Not to mention that it's a really bad idea to just assume that
> if a module compiles against a new major PG version that it works
> correctly. It needs to be tested with that major version and adding an
> extra build-depend is pretty minimial effort compared to properly
> testing any module.
Yes. I've covered that in my proposal by having the following in
pg_buildext build $(SRCDIR) $(TARGET) 8.3 "$(CFLAGS)" && \
dh_install -ppostgresql-8.3-prefix || echo "skipping 8.3"
pg_buildext build $(SRCDIR) $(TARGET) 8.4 "$(CFLAGS)" && \
dh_install -ppostgresql-8.4-prefix || echo "skipping 8.4"
That means that each package has to have its list of supported major
versions hard coded. The pg_buildext tool will exit 1 if the version you
ask it to build for is not a debian supported version.
The other option is the debian/pgversions proposed by Julien, which
would have the same effect but would look more like a dh script. In both
cases the maintainer *has* to decide against which major version the
package is meant to build.
The idea is to avoid editing the package for a testing to stable
migration, not to randomly build against whatever is the current major
versions in the release you happen to be building. IOW, we're in violent
More information about the Pkg-postgresql-public