Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
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? I.e. on a partial upgrade. (Could someone run autopkgtests in
buster with the proposed gdal-data?)
If there are applications known to be broken, we could add versioned
Breaks against them to the new gdal-data.
The following files are removed:
2/usr/share/gdal/compdcs.csv |only
2/usr/share/gdal/coordinate_axis.csv |only
2/usr/share/gdal/datum_shift.csv |only
2/usr/share/gdal/ellipsoid.csv |only
2/usr/share/gdal/esri_Wisconsin_extra.wkt |only
2/usr/share/gdal/esri_epsg.wkt |only
2/usr/share/gdal/esri_extra.wkt |only
2/usr/share/gdal/gcs.csv |only
2/usr/share/gdal/gcs.override.csv |only
2/usr/share/gdal/gdal_datum.csv |only
2/usr/share/gdal/geoccs.csv |only
2/usr/share/gdal/pcs.csv |only
2/usr/share/gdal/pcs.override.csv |only
2/usr/share/gdal/prime_meridian.csv |only
2/usr/share/gdal/projop_wparm.csv |only
2/usr/share/gdal/unit_of_measure.csv |only
2/usr/share/gdal/vertcs.csv |only
2/usr/share/gdal/vertcs.override.csv |only
these are modified:
3/usr/share/gdal/epsg.wkt | 1
3/usr/share/gdal/gdalvrt.xsd | 150 +++
3/usr/share/gdal/header.dxf | 106 --
3/usr/share/gdal/nitf_spec.xml | 538 ++++++++++++-
3/usr/share/gdal/nitf_spec.xsd | 9
3/usr/share/gdal/ogrvrt.xsd | 5
3/usr/share/gdal/osmconf.ini | 19
3/usr/share/gdal/pds4_template.xml | 14
3/usr/share/gdal/plscenesconf.json | 255 ++++++
3/usr/share/gdal/ruian_vf_ob_v1.gfs | 2
3/usr/share/gdal/ruian_vf_v1.gfs | 2
3/usr/share/gdal/s57objectclasses.csv | 6
3/usr/share/gdal/trailer.dxf | 382 +++++++++
and these are new and should not cause any harm
3/usr/share/gdal/gdalmdiminfo_output.schema.json |only
3/usr/share/gdal/pdfcomposition.xsd |only
3/usr/share/gdal/template_tiles.mapml |only
3/usr/share/gdal/tms_LINZAntarticaMapTileGrid.json |only
3/usr/share/gdal/tms_MapML_APSTILE.json |only
3/usr/share/gdal/tms_MapML_CBMTILE.json |only
3/usr/share/gdal/tms_NZTM2000.json |only
3/usr/share/gdal/vicar.json |only
39 files changed, 1352 insertions(+), 137 deletions(-)
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 :-(
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.
Andreas
Reply to: