At the moment I am automating the installation of postgresql and and the
debversion extension. The fact that there is no "unversioned" binary
package makes that harder than necessary: I will have to hardcode
postgresql-X.Y-debversion, and as soon as that deployment recipe need to
be applied to a different Debian version, that will break.

So, please provide an unversioned binary package called
'postgresql-debversion' which depends on the actual package for the
current PostgreSQL version.

Re: Antonio Terceiro 2017-03-14 <20170314200003.xupt5eddlfw5idux@debian.org>

we can't simply put .so files for an arbitrary PostgreSQL version into
a postgresql-debversion.deb because that will break existing
installations on dist upgrade.

What we can do is to "Provides: postgresql-debversion" from each of
the postgresql-X.Y-debversion packages. That should fix your
deployment problem. (However, it won't make upgrades work, because
it doesn't keep the PostgreSQL and extension versions in sync.)

Does that help for your case?

Christoph

Yes, of course. That was not what I suggested.

I don't exactly get why having a package postgresql-debversion that
depends on the postgresql-X.Y-debversion corresponding to the current
X.Y would not work. server and client themselves are already managed
like this for ages.

Re: Antonio Terceiro 2017-03-26 <20170326115924.zykotnwecwpr2kw4@debian.org>
package would be overkill, i.e. double the number of binary packages.

What do you think about the Provides: idea?

Christoph

As you said, it has the issue of not helping with upgrades.

What if, instead of the versioned packages, you provided unversioned
package names, and each package contained one .so for each supported
PostgreSQL version? It seems that postgresql-server-dev-all exists for
exactly this purpose ...

Re: Antonio Terceiro 2017-03-27 <20170326234116.xkcx7wjcyrqsxnmb@debian.org>

True...

This has the problem that the set of supported versions varies over
time, and that it's different in Debian, and elsewhere. We would be
shipping a 9.6-only package in Debian, and a package containing
everything from 9.2 to 9.6 on apt.postgresql.org. The necessary
dependencies would be non-trivial I'd think. Also this would make it
impossible to provide modules packages for the upcoming PostgreSQL 10
version, because "postgresql-debversion.deb" is already in use there.

I agree that the situation is not optimal, but I think what we have
now is the best we could get to over the past years. Unfortunately
this means you'll need to encode some knowledge about the current
PostgreSQL server version in your deployment recipes.

Christoph

We do exactly that in Ruby, and it is manageable. When the set of
supported versions change, we update the list in a central place
(ruby-defaults), and binNMU/fix existing modules. We also make the
dependencies in such a way that a package that contains modules for more
than one version depends on the stuff from _one_ of the versions, but
not from all of them.

Each context (Debian, apt.postgresql.org) could have a different set of
supported versions via something similar to dpkg-vendor.

Are you opposed to this in principle? Or, would you be willing to
support this if the necessary patches are written? (not saying I will do
that, or at least not in the short term :-))

Does this mean that for PostgreSQL 10+ the module packages will have no
version numbers in their names? Or is that just something you reserve
for the very latest version at the time?

It also means that upgrades don't just work.

Re: Antonio Terceiro 2017-03-27 <20170327152137.23l7vyrunt5pmijy@debian.org>

If we have a written plan that addresses the concerns, we should go
for it.

It means we can't ship postgresql-debversion.deb containing 9.2..9.6
and postgresql-debversion.deb containing 10 in the same repository.

Christoph

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

Re: Ole Streicher 2017-08-30 <dbc7b3ab-90a4-215f-ce02-413ced1ff439@debian.org>

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.

Right.

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

Hi Chriostoph,

The idea here is to have just one binary package, containing the shared
libraries for all supported versions. Extensions are usually small, so
combining them in one package will not hurt. So, there would no
"postgresql-9.6-q3c" package anymore, d/control.in is removed, and
d/control is fixed (for one release). For convenience, I just attach the
complete d/control for postgresql-q3c.

In that case, changing the supported postgresql versions will not change
the list of binary packages, but just the dependencies, which is IMO not
forbidden.

Best regards

Ole

Re: Ole Streicher 2017-08-30 <d70bc62a-4f92-cb62-45d7-dce974e2c266@debian.org>

That is true, but it's totally different from what we have been doing
so far. We would need to update all packages, and providing the
necessary (?) transitional packages for existing users will be
difficult.

If a PG version goes out of support, the new package version wouldn't
contain the module anymore, even if users are still using that PG
version on their system. (Think Debian dist-upgrades.)

It would also prevent (easily) building packages against beta/devel PG
versions (10 and 11 at the moment). Or these packages would need to
include the "normal" PG versions from the normal packages, plus the
extra versions.

The idea is intriguing, though. Maybe these problems have cute
solutions and could be fixed.

Christoph

Hi Christoph,
creation is integrated in pg_buildext, then the maintainer can still
choose between the current approach and the single-package approach. It
is just a matter of policy then.

Transitioning should just be possible with an additional field

Provides: postgresql-9.6-debconf, postgresql-10.0-debconf [...]

which also could be supported by a variable {postgresql:Provides},
created similarly to {postgresql:Depends} field.

And if a postgresql version goes out of support, then I would suppose
that the postgresql-XX server package is removed as well? Then, they
couldn't upgrade the package because of the missing postgresql
dependency, and they couldn't upgrade in the old scheme.

But I must say I have no idea how upgrades for Postgresql work, there
may be some problems.

The only difference is that all builds are combined into a single
package. So, whatever can be built in the current scheme, can also be
built then. If "pg_buildext supported-versions" offers experimental
packages, they are also included.

Best regards

Ole

Hi Christoph,

may I ping you here? Postgresql-10 just arrived in unstable (great,
thanks); but I would now rather like to convert to single (and
bin-NMU-capable) packages instead of adding postgresql-10-q3c now, as it
is done f.e. for Python packages.

I would just do this for my own packages (pqsphere and q3c), which would
allow to collect experiences; but ofcourse I don't want to shoot into
your feet with the packaging at the postgresql site.

Best regards

Ole

Re: Ole Streicher 2017-09-22 <e1f46e5e-aca8-5b45-af4a-e5a3272f9335@debian.org>
experiment. The plethora of mini packages we have now isn't ideal.

(While uploading the first batch of PG10 packages, I rediscovered the
fact that the pgagent package is already using such a scheme:

Package: pgagent
XB-Postgresql-Version: ${Postgresql:Version}
Postgresql-Version: 9.2 9.3 9.4 9.5 9.6

The package is pretty small, though, pgagent's extension part is SQL
only, and version-agnostic, only the pgagent client binary needs to be
compiled, and doesn't vary between versions.)

My main concern is supporting upgrades cleanly. Imagine "your" package
had already been around in jessie, and the user had postgresql-9.4 +
postgresql-q3c installed where q3c provided the 9.4 extension. Now the
user upgrades to stretch, gets postgresql-9.6 installed (e.g. via
postgresql.deb), the 9.4 cluster will still work, but the upgraded
postgresql-q3c package from stretch suddenly doesn't provide the 9.4
anymore, but only 9.6, rendering q3c broken in the 9.4 cluster.

Maybe we could just claim that the user should upgrade their database
at the same time, and for many extensions this will not be a problem.
But for extensions providing datatypes (I think that includes q3c),
the .so module is needed for dumping the old data, so at least
dump-restore upgrades are affected. pg_upgrade should still work,
though. (Making pg_upgradecluster use that by default is another
story.)

Christoph

Hi Christoph,

I just uploaded q3c as a single binary package. pgsphere will follow
after some discussion with the main users (hi Markus :-) )
the q3c package would support f.e. 9.6 and 10, it can have

Provides: postgresql-9.6-q3c, postgresql-10-q3c

If you then need q3c for a specific version, you can install/depend on
this specific version. This also allows a smooth transition between the
multi-binary-package approach and the single binary package.

This is already implemented in the uploaded version.

This may indeed need some work; however I need some advice here.

Best regards

Ole

Re: Ole Streicher 2017-09-25 <765c2141-8d1b-44c6-845b-6375d84997f9@debian.org>

Aye, didn't think of that aspect yet.

The problem is that at no point in time both versions are installed,
so upgrading a PostgreSQL cluster via online dump-restore won't work.
We could make that work by supporting both the old and the new
PostgreSQL version in the next release, but that would double the
maintenance effort on the PostgreSQL server packages side. PostgreSQL
major versions are supported upstream for 5 years, but we are
regularly running out of support even with one version in
oldoldstable-lts, that would be much worse if there were two versions
(likely released 2 years apart).

Christoph