Hi,
On Wed, 2 Jun 2021 22:22:04 +0200 Sebastian Ramacher
<sramac...@debian.org> wrote:
Hi Gilles, hi Andreas,
On 2021-06-01 14:15:52 +0200, Andreas Beckmann wrote:
> On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder <d.fil...@web.de> wrote:
> > One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
> > Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
> > and postgresql-11-postgis-2.5 depends on that. libgdal28 depends on
> > gdal-data (>=3.2.1+dfsg-1). To me it looks like there's no way to
> > keep postgresql-11-postgis-2.5 around if anything that depends on
> > libgdal28 (postgis, libopencv-imgcodecs4.5, ...) gets installed.
>
> What would be needed to reintroduce postgresql-11-postgis-2.5 (i.e.
> src:postgis-2.5) (built against bullseye libraries) into bullseye? Probably
> libraries and -dev packages from postgresql-11, too.
> Here I assume that src:postgis-2.5 could be built against gdal 3.2.x and
> that can be used to perform the upgrade to postgis 3.x - is that true?
So here is a different view. At least the hdf5 part of this upgrade
issue could have been avoided if we transitationed to hdf5 1.12 (which
bumps all the SOVERSIONs to 200) for bullseye. Alas, we didn't and it's
too late for that.
So, what if we use the free versions between 103 and 200 to transition
to a Debian-specific version? Attached is a patch that does that. It's
not an optimal solution as we would have a release with a
Debian-specific SOVERSIONs. For good reason, we usually try to avoid
those. So, it would be good for someone more familiar with the users of
hdf5 to check if that would be an issue in this specific case.
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.
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?
Best,
_g.
