On 11/10/19 8:26 PM, Sebastiaan Couwenberg wrote:
The transition to GDAL 3 was blocked by the removal of the Python 2
support as discussed in the transition bugreport (#939989). This took
quite a bit of time to resolve due to an uncooperative maintainer, but
there are no rdeps of python-gdal in unstable any more.
In the meantime the GDAL 3 support in fiona was fixed upstream. vtk7 was
also updated to use the embedded copy of PROJ.4 to fix the FTBFS with
PROJ 6. OSSIM upstream even ported it to use the GEOS C API to fix the
build failure with GEOS 3.8.0. Unfortunately OTB still FTBFS due to
recent changes in ITK4. It's still not in testing, so not a big issue.
Hopefully we'll be able to start the transition soon, but I fear that
the python3.8 transition is going to cause more delays (as it will cause
many autopkgtest failure until everything is rebuilt for python3.8 as well).
networkx continued to delay the transition due to its update breaking
autopkgtests for some of its rdeps, but we just got the go-ahead.
This means we'll build the next QGIS release (3.4.15) with PROJ6 & GDAL3
which it does not support well, fortunately next month (on February
27th) we'll switch to the 3.10 LTR which does have support for PROJ6 &
GDAL3.
There are still some projects that lack support for PROJ6/GDAL3 like
mapserver and qmapshack, these may be broken in the next Ubuntu LTS
(focal) if they transition to GDAL 3 before the import freeze on
February 27th. We'll have more time in Debian to get these packages
fixed before the next stable release.
For Ubuntu endusers it may be better to stick to PROJ6/GDAL2 for focal
due to not all leaf packages supporting GDAL3 yet, for use cases like
Travis-CI it's probably more desirable to have PROJ6/GDAL3 in the next
LTS. I'll leave it to Gianfranco to decide what to do for focal.
Kind Regards,
Bas