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