Bug#1070852: transition: gdal
On Fri, May 24, 2024 at 11:29:46AM +0200, Emilio Pozuelo Monfort wrote:
> On 24/05/2024 11:02, Sebastiaan Couwenberg wrote:
> > On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote:
> > > If that's the case, gdal should probably break older versions of
> > > libgdal-grass so that that combination is not possible. That will
> > > also make britney happy, otherwise it will block gdal due to the
> > > test regression.
> >
> > gdal, grass, and libgdal-grass just need to be tested together.
> >
> > I'd rather drop the autopkgtest test than having to maintain the Breaks in gdal.
>
> *shrug*. If that's a runtime check, then there's an issue with the
> dependencies/breaks, as one could have old libgdal-grass with newer gdal (as
> is happening in the autopkgtest) and then libgdal-grass is broken.
>
> If it's a check that's being done in libgdal-grass, then maybe that check
> can be dropped?
>
> With the information that autopkgtest has, the current situation is broken
> and testing migration will be (rightly) blocked.
This is the old problem that the release team wants smooth transitions,
but mixing several so-versions of a library in one binary works only sometimes.
Symbol versions fix some cases, but even that is not sufficient in all cases.
Package: libgdal35
Breaks: libgdal34t64, libgdal32
would be the safe way to ensure no breakage during upgrades or after a
partial upgrade from bookworm or trixie.
> Cheers,
> Emilio
cu
Adrian
Reply to: