[Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Ole Streicher]

Hi,

maybe I do not fully understand the problem here, but isn't that
solvable easily by changing how d/rules is written? As a first strawman
approach, one could do in d/rules (That is for the upcoming
postgresql-q3c package, which is a very simple one):

-----------------------8<----------------------------------------------
#!/usr/bin/make -f
# -*- makefile -*-

SRCDIR=$(CURDIR)
PG_VERSIONS=$(shell pg_buildext supported-versions | sort -r | sed s/^/postgresql-/)

[...]

override_dh_auto_install:
	+pg_buildext install $(SRCDIR) build-%v postgresql-q3c

override_dh_shlibdeps:
	dh_shlibdeps
	echo "postgresql:Depends=$(PG_VERSIONS)" | sed s/\ /\|/ >> debian/postgresql-q3c.substvars

-----------------------8<----------------------------------------------

The handling of d/control is not needed anymore there (since it is
not generated).

Then, d/control contains:

-----------------------8<----------------------------------------------
Package: postgresql-q3c
Architecture: any
Depends: ${postgresql:Depends},
         ${misc:Depends},
         ${shlibs:Depends}
Description: PostgreSQL extension used for indexing the sky
 [...]
-----------------------8<----------------------------------------------

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).

Ideally the dependency generation could be integrated into pg_buildext.

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.

Is this too short-sighted? Are significant drawbacks here?

Best regards

Ole