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

[Martin Pitt]

Hey Dimitri,

Dimitri Fontaine [2010-01-06 17:50 +0100]:
> So I've finally had some time to spend on this, so please find attached
> a proof of concept debdiff.

Thanks for your work on this. I like the general approach, I'd just
like to discuss some details.

> What's missing is a manpage for the newer /usr/bin/pg_buildext tool
> (is the path right?)

Sounds fine to me.

>, 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.

> 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.

s/migrates/transitions to a new set of supported versions/.

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.

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.

> +
> +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.

> --- postgresql-common-103/pg_buildext	1970-01-01 01:00:00.000000000 +0100
> +++ postgresql-common-104/pg_buildext	2010-01-06 17:35:13.000000000 +0100
> @@ -0,0 +1,45 @@
> +#!/bin/bash

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

> +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.)

> +
> +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.

> +for v in `/usr/share/postgresql-common/supported-versions`
> +do
> +    if [ $v == $version ]; then
> +	if [ "$action" = "supported" ]; then
> +	    exit 0
> +	else
> +	    $action $v && exit 0
> +	fi
> +    fi
> +done

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

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

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)