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

Christoph Berg myon at debian.org
Sat Sep 30 09:40:46 UTC 2017


Re: Ole Streicher 2017-09-25 <765c2141-8d1b-44c6-845b-6375d84997f9 at debian.org>
> 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.

Aye, didn't think of that aspect yet.

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

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



More information about the Pkg-postgresql-public mailing list