Re: Ole Streicher 2017-09-22 <e1f46e5e-aca8-5b45-af4a-e5a3272f9...@debian.org>
> 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.
The plan seems sensible, so please go ahead, it will be an interesting
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
