Обсуждение: Updated pg_buildext

Hi,

here's my updated pg_buildext script. Most notable changes are the
addtion of the "configure" and "install" actions and that it catches
more errors (set -e, die() calls).

Dimitri, do you think that should go into the next postgresql-common
version?

(Todo: think about a smart and policy-compliant way to update
debian/control. Also, try using with 9.1 modules.)

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

Hi,

Christoph Berg <myon@debian.org> writes:
> here's my updated pg_buildext script. Most notable changes are the
> addtion of the "configure" and "install" actions and that it catches
> more errors (set -e, die() calls).

I like your changes!

I recall that doing the build in the vtarget directory was important in
my usage, but it could be that you new -f $makefile style allows to run
the build from any directory…

> Dimitri, do you think that should go into the next postgresql-common
> version?

Yes.

> (Todo: think about a smart and policy-compliant way to update
> debian/control. Also, try using with 9.1 modules.)

As we rely on the extension's Makefile I think we're as good as can be
for 9.1.  For debian/control, we have the mechanism to automatically
derive it from supported-versions, we need to reach on a conclusion
about its use being safe.

The other TODO would be what to do about VPATH unfriendly extensions.
Some of them are using subdirectories where to stash regression tests,
docs, etc.  Then building from another place is a problem:  maybe that's
why you removed my forcing building in $vtarget?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

Re: Dimitri Fontaine 2011-06-18 <m2sjr7m9ra.fsf@2ndQuadrant.fr>
> I recall that doing the build in the vtarget directory was important in
> my usage, but it could be that you new -f $makefile style allows to run
> the build from any directory…

I didn't really change that, I just replaced "cd && make" with "make -C".

Usually, there won't be a Makefile in the build directory, so
$makefile is "-f $srcdir/Makefile" as before. The other case was added
for plsh which uses autoconf.

(build)
-    cd $vtarget
-    make -f $srcdir/Makefile CFLAGS="$cflags $opt" PG_CONFIG="$pgc" VPATH="$srcdir"
-    cd -
+    # if a Makefile was created by configure, use it, else the top level Makefile
+    [ -f $vtarget/Makefile ] || makefile="-f $srcdir/Makefile"
+    make -C $vtarget $makefile CFLAGS="$cflags" PG_CONFIG="$pgc" VPATH="$srcdir"

> > (Todo: think about a smart and policy-compliant way to update
> > debian/control. Also, try using with 9.1 modules.)
>
> As we rely on the extension's Makefile I think we're as good as can be
> for 9.1.  For debian/control, we have the mechanism to automatically
> derive it from supported-versions, we need to reach on a conclusion
> about its use being safe.

The thread on debian-release wasn't 100% conclusive, but there were
voices against automatically updating:

http://lists.debian.org/debian-release/2011/04/msg00413.html

Here's what I would do:

* add all supported (by the package) versions to debian/control, but
  only build those from supported-versions
* have some way to update debian/control (ideally not involving
  debian/control.in because manual changes to debian/control get lost)
* have some way to indicate that we want to build a different set of
  versions, 1) it would make sense to build 9.1 modules when uploading
  to experimental now, 2) we need that for apt.postgresql.org

> The other TODO would be what to do about VPATH unfriendly extensions.
> Some of them are using subdirectories where to stash regression tests,
> docs, etc.  Then building from another place is a problem:  maybe that's
> why you removed my forcing building in $vtarget?

These probably require full (configure,) build && install cycles for
each version. Usually install is invoked via fakeroot, but maybe we
can go without.

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

Christoph Berg <myon@debian.org> writes:
> I didn't really change that, I just replaced "cd && make" with "make -C".

Ahah, I missed that.  Objection withdrawn! :)

> Here's what I would do:
>
> * add all supported (by the package) versions to debian/control, but
>   only build those from supported-versions
> * have some way to update debian/control (ideally not involving
>   debian/control.in because manual changes to debian/control get lost)
> * have some way to indicate that we want to build a different set of
>   versions, 1) it would make sense to build 9.1 modules when uploading
>   to experimental now, 2) we need that for apt.postgresql.org

Well, for the “local” set of versions to build, I think the answer is to
tweak (dpkg-divert) the supported-versions script.  Other than that, the
main situation I want to avoid is having to hand-edit the package when a
major version of PostgreSQL is dropped from sid at testing freeze time.

So +1 for your proposal.

>> The other TODO would be what to do about VPATH unfriendly extensions.
>> Some of them are using subdirectories where to stash regression tests,
>> docs, etc.  Then building from another place is a problem:  maybe that's
>> why you removed my forcing building in $vtarget?
>
> These probably require full (configure,) build && install cycles for
> each version. Usually install is invoked via fakeroot, but maybe we
> can go without.

I guess it boils down to playing with each extension in debian and
seeing where pg_buildext fails…

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

Hello Christoph,

Christoph Berg [2011-06-17 17:25 +0200]:
> here's my updated pg_buildext script. Most notable changes are the
> addtion of the "configure" and "install" actions and that it catches
> more errors (set -e, die() calls).

Thanks! Updated in VCS, I'll do a new upload soon.

Martin

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