[Pkg-postgresql-public] Dropping postgresql 8.3 for squeeze
Stephen Frost
sfrost at snowman.net
Wed Jan 6 18:21:12 UTC 2010
Dimitri,
* Dimitri Fontaine (dfontaine at hi-media.com) wrote:
> What remains to be done would be, apart from adapting some more packages
> to use the tool, to handle build-dependancies at this level. The prefix
> package for example now has:
>
> Build-Depends: debhelper (>= 7), postgresql-dev-common,
> postgresql-server-dev-8.3, postgresql-server-dev-8.4
>
> Those last two dependencies could go to postgresql-dev-common, that
> you'd maintain for us all so that I don't have to change this when the
> package migrates. Then there's the dynamic debian/control issue that I
> don't know how to tackle yet. Will RTFM about this clue you gave me.
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.
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.
Thanks,
Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/attachments/20100106/9ec8f3e6/attachment.pgp>
More information about the Pkg-postgresql-public
mailing list