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

Dimitri Fontaine dfontaine at hi-media.com
Mon Dec 7 15:30:02 UTC 2009


Hi,  Martin Pitt <mpitt at debian.org> writes: > We currently have 
PostgreSQL 8.3 and 8.4 in sid/testing. Just as in > Lenny we only 
want to support the latest major release in squeeze, and > let the 
postgresql-common architecture handle upgrades. With the > freeze 
being three months out, we should now start to clean up the 8.3 > 
stuff.   Ok. But will we deprecate 8.3 out of sid/testing ?  And 
we will soon have 8.4 and 8.5 in sid, anyhow.   > already builds 
8.4 extension, needs dropping of obsolete b-dep: > 
--------------------------------------------------------------- > 
> hstore-new: b-d postgresql-server-dev-8.3, 
postgresql-server-dev-8.4 > prefix: postgresql-server-dev-8.3, 
postgresql-server-dev-8.4 > preprepare: postgresql-8.3-preprepare, 
postgresql-8.4-preprepare  I have another proposal to better 
support more than one PostgreSQL version at the same as far as 
extensions are concerned, inspired by what is done for python. 
We'd need a postgresql-server-dev package providing the binary 
tool pgversions, maybe with some switches -s and -i (supported and 
installed versions of PostgreSQL). And I'd like to offer a -e 
switch too, which would export in the environment the paths of the 
tools we use, in order to avoid having to do that kind of things: 
PG_CFG83 = /usr/lib/postgresql/8.3/bin/pg_config PG_CFG84 = 
/usr/lib/postgresql/8.4/bin/pg_config  CFLAGS83 = $(shell 
$(PG_CFG83) --cflags) CFLAGS84 = $(shell $(PG_CFG84) --cflags) 
Then, prefix plus postgresql-8.4-prefix etc would become 
postgresql-prefix, and in debian/rules at build time we'd use the 
override_dh_auto_install rule to build for each supported version: 
override_dh_auto_install:
         for v in `pgversions -e -s`; do \ make VPATH=$(SRCDIR) 
            DESTDIR=debian/tmp install \
         done

Now dh_install will package all the installed files in debian/tmp,
meaning several .so and .sql for each supported version.

The trick would then for you to provide a pgversions binary which
reports only 8.4 in squeeze but another list in sid, and with the
associated dependancies so that postgresql-server-dev-8.X are all
installed to.

This way I wouldn't have to desupport a PostgreSQL version from my
source packages, and if the other maintainers where to follow the model
they would have no work to do when we change the list of supported
PostgreSQL version in a release cycle.

Of course, the extensions themsleves have to build for several major
versions from the same sources, but that's how it works in general.

Regards,
-- 
dim





More information about the Pkg-postgresql-public mailing list