[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