[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28



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? Are there any changes in 3.2.2 that go
beyond targetted fixes? Is there a policy that gdal upstream follows for
picking patches for a bug fix release?

Cheers

> 
> 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


Reply to: