On 6/18/21 5:19 PM, Andreas Beckmann wrote: > On 18/06/2021 09.50, Sebastiaan Couwenberg wrote: >> I'm increasingly in favor of removing the Breaks from gdal-data, the >> attached procedure works for me in buster chroot. > >> There is much less need for gdal-data breaking libgdal20 for us than >> there is in the UbuntuGIS PPA use case. I'm not aware of any packages >> that use gdal in the maintainer scripts that would be using the old gdal >> on their removal. So there shouldn't be any actual expected breakage. > > Do you have some ideas what could break by installing gdal-data 3.x in > buster?
qgis crssync is a likely candidate, prior to PROJ 6 it relied more more heavily on the projection data included in gdal. Other than that I don't know. You'd have to grep through the sources to find the functions using those files, and then search through reverse dependencies for use of those functions. > I.e. on a partial upgrade. (Could someone run autopkgtests in > buster with the proposed gdal-data?) Many of the gdal rdeps don't have autopkgtests, and the most prominents ones don't. >> This change is minimal, doesn't require NEW packages, nor introduces >> divergence from upstream (as when the files would be moved to >> u/s/gdal/<X.Y> in libgdal28), hence it's my preferred solution. > > That's a bad upstream decision, but as you described them, they don't > care about upgrade paths :-( PostGIS upstream are the ones who don't particular care about distribution upgrades. GDAL upstream is actually quite good (and responsible for the bulk of the work that went into PROJ 6). >> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the >> changes from the debdiff to unstable. > > Sounds fine to me. If the RMs are onboard as well, then let's not waste any more time on alternatives. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
