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

[Ole Streicher]

Hi Christoph,

On 23.09.2017 21:41, Christoph Berg wrote:
> Re: Ole Streicher 2017-09-22 <e1f46e5e-aca8-5b45-af4a-e5a3272f9335 at debian.org>
>> 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.

I just uploaded q3c as a single binary package. pgsphere will follow
after some discussion with the main users (hi Markus :-) )

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

This can be addressed by introducing Postgresql-versioned Provides. If
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.

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

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

Best regards

Ole