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

Dimitri Fontaine dfontaine at hi-media.com
Mon Jan 11 09:54:19 UTC 2010

Martin Pitt <mpitt at debian.org> writes:
> Thanks for your work on this. I like the general approach, I'd just
> like to discuss some details.

Globally we're on the same page, the inconsistencies and quote missing
etc are due to it being a quick and dirty POC to know if I'll be
spending some more time on it. I'll do.

>>, but I'm confused about how you manage the sources of yours. Do you
>> directly edit the nroff version?
> The manpages for the perl programs are generated with pod2man from the
> POD in the source. There are two manpages for data formats
> (postgresqlrc.5 and user_clusters.5) which I just wrote manually; I
> could also have used POD for that.
> So, feel free to use POD or manual writing whatever you prefer.
> A manpage for this program would be highly appreciated indeed.

I now usually use asciidoc (then xmlto) to produce my man pages, would
that be acceptable a build-depends for you?

>>   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.
> s/migrates/transitions to a new set of supported versions/.

Yeah. I'll adapt to using non-controversial vocabulary. Steep learning
curve, as they say.

> I don't like doing this, since it would mean to break all packages
> without them even noticing. debian/control should have explicitly
> versioned build dependencies and binary package records.

Mmmm, in fact it's meant to serve the case when you deprecate say 8.3
from sid to prepare migration. In this case I'd like to not have to
manually prepare the transition.

Then you still get to explicitely state as a packager which PostgreSQL
major version you support, and those only get built if so says

I'm failing to see under which scenario it'd break silently.

> Of course I'm open to adopting a helper tool which produces
> debian/control from a debian/control.in. E. g. it could search for
> records
>   Package: postgresql-foo-PGVERSION
>   [...]
>   Description: foo extension for PostgreSSQL PGVERSION
> replicate this stanza for each supported version, and replace
> PGVERSION with the actual version. This helper tool could be realized
> as a Makefile snippet, which would be included into debian/rules. It
> could be called with "debian/rules build-control", for example.

Will work on this, that's the tool which will need a debian/pgversions
file (to mimic pyversions) where the packager states against which major
versions the extension does build.

>> +Package: postgresql-dev-common
> I'm pondering whether this small script already justifies a new binary
> package. For now we could probably just stuff it into
> postgresql-common.

Ok, that was for build-depends later.

> This should enable "set -e", and I guess /bin/sh should be enough.

ok for set -e, see above for /bin/sh.

>> +action=$1
>> +srcdir=$2
>> +target=$3
>> +version=$4
>> +opt=$5
> For robustness' sake all the variables should be quoted (here and
> below). (I'll do that when I commit this to p-common, just thinking
> aloud.)

Will use getopt here, so I guess it's back to /bin/bash.

>> +
>> +function prepare_env() {
>> +    version=$1
> You already have global variables $action and $version, why not just
> use them? Mixing those seems confusing to me.
>> +    target=`echo $target | sed -e "s:%v:$version:"`
> Ah, so that substitution one important detail that should be
> highlighted in the manpage.


> Please use consistent indentation (also just note to myself).

Will do, that was quick and dirty.

> Thanks again. Will commit this once above questions are settled, and
> there's a manpage.

I'll send a new version soon'ish hopefully, thanks for your support!


More information about the Pkg-postgresql-public mailing list