Control: reassign -1 postgresql-13-postgis-3
Andreas Beckmann a écrit le 08/06/2021 à 08:27 :
An alternative solution would be to rename libhdf5*-103-1 back to
libhdf5*-103 and add dependencies on the split out libraries (s.t. e.g.
dependencies of a buster package depending on libhdf5-103 for a -hl
library are still satisfied). These Depends can be removed once the 103
SOVERSION gets bumped.
I don't think so. The problem is in postgis which *requires* a 2.5
runtime to migrate databases from buster to bullseye.
I acknowledge and regret that this 103 to 103-1 hdf5 transition (*) is
unfortunate and doesn't help at all with a workaround, but this is not
where the problem lies in the first place. This painful postgis
migration experience seems well [0] known [1] and documented [2] at
several places.
[0]
https://stackoverflow.com/questions/63413582/can-not-upgrade-postgis-2-5-to-3-0-1-for-postgresql-11-on-ubuntu
[1] https://github.com/postgis/docker-postgis/issues/207
[2]
https://oslandia.com/en/2020/11/05/mettre-a-jour-vos-vieux-clusters-postgis/
The only solutions I can see are either to document postgis databases
manual migration (such as in [2]) or to reintroduce a minimal
postgis-2.5 runtime built against postgresql 13 to fix the scripted
migration procedure.
(*) As a side note, this hdf5 transition was triggered by an hdf5
Fortran API SONAME bump while the SONAME for the C library wasn't
changed. All the hdf5 runtime libraries now have their own binary
package to prevent such a Breaks / Replaces transition to happen again.
Best,
_g.