Package: postgresql-13-pgsphere Version: 1.1.1+2020-10-20-1 Severity: serious Control: clone -1 -2 Control: reassign -2 postgresql-13-q3c 2.0.0-4 Control: retitle -1 postgresql-13-q3c: drop Conflicts+Replaces: postgresql-q3c
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984555#44 Markus Demleitner <msdem...@ari.uni-heidelberg.de> wrote: > 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. This is currently not possible, since postgresql-13-pgsphere has Conflicts+Replaces: postgresql-pgsphere (<< 1.1.1+2020) (and C+R: postgresql-q3c (<< 2.0.0-2) for postgresql-13-q3c). I do not know if other extension packages have the same bug. (gavodachs2-server seems to be one of the few packages actually needing some extensions (pgsphere and q3c) and thus exhibiting upgrade errors.) I think these Conflicts+Replaces can be safely dropped, since all files in these packages are in versioned (/13/) paths and therefore cannot cause file conflicts with the unversioned package in buster that ships everything (but documentation) in versioned (/11/) paths. But I may be overlooking something ... Andreas
