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
