[Debian-astro-maintainers] Bug#984555: gavodachs2-server: fails to install/upgrade. breaks on executing SQL script.

[Markus Demleitner]

Hi Andreas,

On Mon, May 03, 2021 at 07:19:52PM +0200, Andreas Beckmann wrote:
> Followup-For: Bug #984555
> I think I have an idea what is happening: The upgrade from buster to
> bullseye does not install postgresql-13-pgsphere and postgresql-13-q3c
> but keeps postgresql-pgsphere and postgresql-q3c from buster installed.

Yes, that's my analysis, too.

> This is a problem of the postgresql-* packages which switched from real
> packages postgresql-foo providing virtual postgresql-xx-foo to real
> packages postgresql-xx-foo providing virtual postgresql-foo.
> IMO it was wrong turning postgresql-foo into virtual packages,
> especially if multiple postgresql-xx-foo are expected to be
> co-installable, s.t. there are multiple packages providing
> postgresql-foo at the same time. postgresql-foo should have stayed a
> real package depending on the default version of postgresql-xx-foo.

Ah.  That might be a solution.  One thing that needs to be
ensured, though, is that on upgrades, the old pgsphere packages do
not get removed until the operator asks dpkg to explicitly.  Perhaps
stating the obvious, here's what needs to happen when upgrading from,
say pg 11 to 13:

(1) normal dist-upgrade pulls in (hopefully) postgres-13, keeps
    postgres-11 running as normal (hence, pgsphere-11 must still be
    there).
(2) operator runs pg_upgrade (for which both pg-13 and pg-11 must be
    present with all necessary extensions)
(3) the last step of pg_upgrade is to make pg-13 the default db server,
    and pg-11 isn't started any more
(4) the operator can now purge postgres-11 together with the
    version 11 extensions.

My hunch is that when pgsphere-11 is installed as an auto-dependency
of pgsphere, it will be dropped in step (1), at which point pg-11
probably won't even start any more, or at least will be unable to
dump for the pg_upgrade.

> and reducing that to
> 
>   Depends: adduser, members, postgresql-13-pgsphere, postgresql-13-q3c, python3-gavo (= 2.3+dfsg-2)

I've just done this, and I *think* that should do the right thing
when upgrading to bullseye.  I can't say I like it much, though, in
particular because it's going to be a permanent chore in maintaining
the explicit versions.

What I'd *really* want to say is:

"I depend on a postgres with the pgsphere and q3c extensions
installed, listening on port 5432."

How far we get there with the existing Depends logic would be
something I'd probably ask the postgres folks.

> 
> Perhaps also a
> 
>   Breaks: postgresql-pgsphere (<< 1.1.1+2020), postgresql-q3c (<< 2)
> 
> would work for the upgrades to bullseye.

Nah, that, I think, would be a disaster, because it'd throw out the
extensions before step (2) above could run, no?

Even though I think the problem is addressed for bullseye, I'm
leaving this bug open because I'm hoping for some better way to solve
this.