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
Attachment:
signature.asc
Description: OpenPGP digital signature