On 1/11/20 9:48 PM, Paul Gevers wrote: > gdal triggers autopkgtest regressions in two packages and looking at the > logs I am wondering if that point to a missing dependency relation, as > the tests pass in unstable once they were binNMU'ed. > > In both tests, libgdal20 from testing is installed (due to the package > in testing not being build against the new library) but the new > gdal-data package is installed. Both tests show: > ERROR: GDAL OpenFailed [4] Unable to open EPSG support file gcs.csv. > Try setting the GDAL_DATA environment variable to point to the directory > containing EPSG csv files.
I saw that, and it shouldn't pull in only gdal-data from unstable. That seems like an issue in autopkgtest. > Is this something that needs fixing in the gdal package somehow? I don't think so. > Probably I am saying something stupid, but e.g. gdal-data (<new>) breaks > libgdal* <old>. I notice that the library already has a larger than > relation on gdal-data, but apparently there should have been a smaller > than relation as well. (As we can't fix the package in testing, I > proposed the breaks). > > Can you please share your view of this problem? This kind of inter-package dependency should use "(= ${source:Version})" like done between arch:any packages with "(= ${binary:Version})", but using the exact source version between arch:any and arch:all packages breaks arch:all binNMUs, so >= is used instead. I don't think the gdal source should be changed just to accommodate debci. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
signature.asc
Description: OpenPGP digital signature