Re: Ole Streicher 2017-08-30 <dbc7b3ab-90a4-215f-ce02-413ced1ff...@debian.org>
> For Debian (single Postgresql version) this works well; I don't know
> if "pg_buildext supported-versions" returns them line by line (what I assumed)
> or space-separated (then it needs some adjustments). One should also discuss
> which Postgresql version should be the first (which installed by default).
It's line-separated.
Re the default version, the convention is that
/usr/share/postgresql-common/supported-versions returns the default
version /last/. (Try calling
PG_SUPPORTED_VERSIONS=pgdg /usr/share/postgresql-common/supported-versions
).
I'm not sure if "pg_buildext supported-versions" preserves that
ordering in all cases; but we can fix it to do so if it's not already
the case. Then there is the question what to do if the default version
is not in the intersection of "debian/pgversions"
`/usr/share/postgresql-common/supported-versions`, which is what
`pg_buildext supported-versions` really computes.
> Ideally the dependency generation could be integrated into pg_buildext.
Right.
> If a new Postgresql version is uploaded (or an old one is removed), a
> binNMU can be requested, resulting in a new package with the new list of
> Postgresql objects built in. As it is done for Python or others.
BinNMUs would work for updating the ${postgresql:Depends} part. What
doesn't work is changing the set of binaries built from
debian/control, because it's forbidden by Debian policy. This is why
"pg_buildext checkcontrol" raises an error if the file changes.
Possibly we could make it smarter, but in most cases, changing the
default version will mean the list of supported versions changes as
well.
Christoph
