[Pkg-postgresql-public] Dropping postgresql 8.3 for squeeze

[Dimitri Fontaine]

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
debian/rules:

	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
agreement :)

Regards,
-- 
dim