On 2021-06-11 21:21:09 +0200, Sebastiaan Couwenberg wrote: > On 6/11/21 8:49 PM, Sebastian Ramacher wrote: > > On 2021-06-09 12:41:29 +0200, Sebastiaan Couwenberg wrote: > >> 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. > > > > Is 3.2.2 a bugfix only release? > > It is. As mentioned in its NEWS: > > https://github.com/OSGeo/gdal/blob/v3.2.2/gdal/NEWS Thanks, that looks sane enough. I have unblocked gdal. Please go ahead with an upload adding a gdal3-data binary package. Cheers > > > Are there any changes in 3.2.2 that go > > beyond targetted fixes? > > I'd say no, see: > > https://github.com/OSGeo/gdal/compare/v3.2.1...v3.2.2 > > > Is there a policy that gdal upstream follows for > > picking patches for a bug fix release? > Its not codified, but upstream is sane with the commits to their > maintenance branches. > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -- Sebastian Ramacher
Attachment:
signature.asc
Description: PGP signature