On 11/19/23 09:34, Paul Gevers wrote:
On 19-11-2023 09:06, Sebastiaan Couwenberg wrote:
britney only schedules:
gdal/3.8.0+dfsg-1
src:gdal from unstable
Likely 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.
If there is a newer version of the libgdal-grass source or binary
packages britney should also try with those in addition to just gdal.
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 is not the most problematic dependency, gdal is:
ERROR 1: OGR/GRASS driver was compiled against GDAL 3.7, but the
current library version is 3.8
This will never work with libgdal-grass from testing, you need the
version from unstable which was rebuilt as part of the transition.
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?
It should work with the version from testing, the version check in
libgdal-grass will succeed with the grass version from testing.
Just tested in a trixie chroot, both libgdal-grass and gdal packages
from unstable are required, grass from testing suffices.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
