GDAL 2.0.0
Triggered by the vote [1] to bless GDAL 2.0.0RC1 as final I updated the
gdal packaging for the GDAL 2.0.0 pre-releases.
Since we currently still have GDAL 1.11.2 in experimental, I've created
{upstream,experimental}-2.0 branches [2][3] in git for the GDAL 2.0
(pre-)releases.
I've forwarded all patches [4][5][6][7] that were not Debian specific,
and marked the others accordingly (Forwarded: not-needed). Almost all
these changes made it into GDAL 2.0.0RC2, #5995 missed one patch
(initalize-typo) and #5996 didn't apply the 'doc' patch. The 'hardening'
patch (#5998) hasn't been applied yet.
One of the major changes to the Debian packaging for GDAL 2.0.0 is the
switch to the system libtiff & libgeotiff instead of the internal copies
in GDAL. The system libtiff & libgeotiff have the required BigTIFF
support now.
We still need to start the gdal transition, but some more changes to the
dependencies are required to deal with the unstable C++ ABI [8]. It
looks like we're back to appending the upstream version to the library
package name to for dependency changes when reverse dependencies are
(re)built with a newer gdal upstream version. The alternative dependency
for the C++ symbols doesn't have much added value over upstream version
specific library packages.
I'll adapt both the GDAL 1.11.2 and 2.0.0 packaging to use the new
library package names, and drop the alternative dependency for C++ symbols.
Since the package will have to pass NEW again after this change it might
take awhile to get it into experimental despite the recent speedup in
NEW processing.
With that in mind it may be a better use of our time to move to GDAL
2.0.0 and skip 1.11.2 for unstable. For now I still prefer to first move
GDAL 1.11.2 from experimental to unstable so we can use experimental for
GDAL 2.0.0. I expect we'll need to resolve quite a number of issues in
the reverse dependencies to work with GDAL 2.0.0 before we can consider
it for unstable. Currently we can move GDAL 1.11.2 to unstable already
when we get the go-ahead from the Release Team, we only need to fix the
library dependencies.
I don't want to wait any longer for fixes addressing the
spatialite_init() deprecation, we still need GDAL 1.11 or newer for
that. But since we also need at least SpatiaLite 4.1.2 we can't fix it
entirely before we transition to SpatiaLite 4.3.0 which hasn't been
released yet. With GDAL 1.11.2 we at least gain the spatialite_init_ex()
support.
What do you think we should do for the gdal transition?
And do you have any thoughts about GDAL C++ symbols and libgdal
dependencies issue?
[1] http://lists.osgeo.org/pipermail/gdal-dev/2015-June/042026.html
[2]
http://anonscm.debian.org/cgit/pkg-grass/gdal.git/log/?h=experimental-2.0
[3] http://anonscm.debian.org/cgit/pkg-grass/gdal.git/log/?h=upstream-2.0
[4] https://trac.osgeo.org/gdal/ticket/5995
[5] https://trac.osgeo.org/gdal/ticket/5996
[6] https://trac.osgeo.org/gdal/ticket/5997
[7] https://trac.osgeo.org/gdal/ticket/5998
[8] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756867#112
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: