Re: [Pkg-postgresql-public] Dropping postgresql 8.3 for squeeze
Hi, Martin Pitt <mpitt@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
Reply to: