From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extensions, patch v16 |
Date: | 2010-12-10 19:38:38 |
Message-ID: | 8F791603-F3F8-42DF-B6DF-66B339A81B43@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Dec 10, 2010, at 11:28 AM, Dimitri Fontaine wrote:
> Well the Makefile support is just a facility to fill in the control file
> automatically for you, on the grounds that you're probably already
> maintaining your version number in the Makefile. Or that it's easy to
> get it there, as in:
>
> EXTVERSION = $(shell dpkg-parsechangelog | awk -F '[:-]' '/^Version:/ { print substr($$2, 2) }')
>
> That comes from a real world example that's yet to be adapted to being
> an extension in 9.1, but still:
>
> https://github.com/dimitri/pgfincore/blob/debian/Makefile
I use that in pgTAP, too (line 23):
https://github.com/theory/pgtap/blob/master/Makefile
But I don't need core to support that. Frankly, if we're not going to generate the control file from Makefile variables, then I'd rather not have any control file Makefile variables at all.
> Upgrade are left for a future patch, did we decide. Still, it seems to
> me that we will support some upgrade scripts so that author can decide
> what to do knowing current and next version, and yes, knowing that the
> module has already been taken care of by the OS-level packaging.
Yeah, this will be needed ASAP.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-12-10 19:42:24 | Re: Extensions, patch v16 |
Previous Message | BRUSSER Michael | 2010-12-10 19:29:20 | Re: initdb failure with Postgres 8.4.4 |