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

[Dimitri Fontaine]

Martin Pitt <mpitt at debian.org> writes:
> I think what you have in mind is already there. Calling
> /usr/share/postgresql-common/supported-versions will print out a list
> of major versions which are supported on the current release
> (Debian/Ubuntu). I maintain that to provide correct debconf obsoletion
> messages on upgrades, but it will work just as well as a build
> dependency and in debian/rules.

Excellent, I missed it!

> Then you don't need to change debian/rules any more, and just need to
> change the build dependencies and binary package names in
> debian/control if the set of supported versions changes.

And debian/postgresql-8.X-prefix.{dirs,docs,install} too, but that might
be tied to my current way of organizing my packages.

That still means manual editing of the package each time we change
supported versions. Easy and all, but is it really necessary:

> Please note that there is deliberately not a versionless p-server-dev
> package (similar to the "postgresql" and "postgresql-client"
> metapackages). If that would just change from 8.3 to 8.4 silently,
> this would break buildability of all extension packages, since often
> they need to be adapted to work with the new version (if nothing else,
> then you at least need to update the package names from e. g. -8.3 to
> -8.4).

That's why I proposed having a single binary package for any extension,
embedding support for more than one major version of PostgreSQL. That
would match how the code is maintained.

That would mean e.g. postgresql-prefix package would contain both the
8.3 and the 8.4 .so though: it would not be necessary to edit the
package for migrating it from testing to stable, but stable would still
contain support for more than needed.

I though of a dh_pgstrip utility maybe, but that'd be run at building
time and migrating the package will not trigger building it, right?

> Does that provide what you need?

Pretty much, thx !

Only thing left is how to avoid having to edit the packages when testing
is becoming stable. I'm not sure if we can avoid it though, but if I
don't ask I won't know :)

Regards,
-- 
dim