Re: Updated pg_buildext

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