On 6/9/21 12:11 PM, Andreas Beckmann wrote: > On 08/06/2021 11.56, Andreas Beckmann wrote: >> 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). > > If the gdal-data issue is solved, the next problem shows up: > > libgdal20 Depends: libogdi3.2 > libgdal28 Depends: libogdi4.1 > > but the two ogdi library packages are not co-installable (both ship > plugins in the same unversioned path). > > So even if we fix hdf5, libgdal20 is unlikely to be able to survive > upgrades from buster. (Sime something that was built against libgdal20 > in buster now likely depends on libgdal28 in bullseye) > But I'd still like to add a Breaks: libgdal20 to libgdal28 to make this > explicit, since transitive Breaks don't work well.
I'm only willing to update gdal in unstable if the 3.2.2+dfsg-1 changes don't need to be reverted. Since that goes against the freeze policy, that's highly unlikely as the RMs seem unwilling to make exceptions. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
