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
