Dimitri Fontaine wrote: > Hi, Martin Pitt <[email protected]> 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.
This would not work without rebuilding everything in testing which would create a chicken and egg problem: we want to have everything tested and build in unstable before migrating it to testing... Cheers Luk -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
