On 6/8/21 11:56 AM, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > > Let's start with the debian-release@ discussion here, this may be turned > into an unblock request later. > > 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. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988722#31 > > gdal can rename gdal-data to gdal3-data, build with > --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20. > Thus libgdal20 + gdal-data from buster should be co-installable with > libgdal28 + gdal3-data from bullseye and survive the upgrade if needed. > > A patch doing this is attached, I'm now testing the upgrade paths > (along the introduction of the libhdf5*-103 metapackages). > > A good gdal bug to reuse would be #986975 > > Updating gdal may be a bit more tricky, because testing has 3.2.1 while > sid has 3.2.2.
gdal won't be updated in unstable before the bullseye release as mentioned in #986975. You don't need to worry about the old postgis, using pg_upgradecluster for postgis databases is not supported. PostGIS databases need to be recreated after the distribution upgrade or hacks need to be used, this is nothing new (but hopefully the bookworm distribution upgrade will be better if it also has postgis 3.x). Please spend your time on other more deserving packages. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
