Hi, On 19-11-2023 09:06, Sebastiaan Couwenberg wrote:
britney only schedules: gdal/3.8.0+dfsg-1 src:gdal from unstableLikely because there is no new version for the libgdal-grass source package, only a binNMU.
Well, because there's no relation that tells britney this combination is no good.
libgdal-grass (1:1.0.2-6+b1) has these dependencies to reflect the tight coupling:grass831 (provided by grass-core) libgdal34 (>= 3.8.0)
It *might* [1] be missing the upper limit (or some binary of gdal missing a breaks relation)? In other words, yes, libgdal-grass from unstable will pull in the right (current) version, but libgdal-grass (or other binary from libgdal-grass) in testing doesn't know it's broken with the version of src:gdal from unstable.
grass-core in testing depends on the old libgdal33, hence the need to also get grass and libgdal-grass from unstable when running autopkgtest with gdal from unstable.
Why? (In other words, what breaks exactly?) Is this a case where some binaries load the old library and others load the new one leading to symbol clashes?
Paul[1] and maybe not, the autopkgtest, binNMU and transitions situation isn't britney's strongest side
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature