On 07/06/2021 22.04, Gilles Filippini wrote:
I'm not in favor of that. I can't understand why we'd need to bump the
HDF5 C library's SONAME for no reason but postgis wants an old runtime
to properly run a migration. That's awkward.
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.
Or, wait, easier: we can reintroduce metapackages libhdf5*-103 depending
on libhdf5*-103-1 and all the other packages containing libraries that
were in the merged package in buster. Nothing in bullseye will depend on
them or need to be rebuilt. But packages from buster depending on
libhdf5*-103 will be allowed to "survive" the upgrade.
I actually like that solution and will try to come up with a patch ;-)
A small problem are the fortran libraries that had their SOVERSION
bumped from 100 to 102, but at least in bullseye there seem to be no
dependencies on them outside of hdf5 itself:
libhdf5-fortran-102
Reverse Depends:
libhdf5-dev
libhdf5-hl-fortran-100
libhdf5-mpich-fortran-102
Reverse Depends:
libhdf5-mpich-dev
libhdf5-mpich-hl-fortran-100
libhdf5-openmpi-fortran-102
Reverse Depends:
libhdf5-openmpi-dev
libhdf5-openmpi-hl-fortran-100
That would have to be carefully checked for buster and maybe some
versioned Breaks against direct users of the fortran libs need to be added.
If postgresql-11-postgis-2.5 needs to be re(instroduced, then it has to
be built against current gdal and hdf5. Is that not feasible?
It's more about allowing postgresql-11-postgis-2.5 to survive the
upgrade from buster long enough s.t. it can be used for the database
migration.
Andreas
