Re: GDAL 2.0.0

[Sebastiaan Couwenberg <sebastic@xs4all.nl>]

On 06/14/2015 11:33 PM, Sebastiaan Couwenberg wrote:
> 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.

GDAL 2.0.0 was released yesterday after blessing 2.0.0RC2. The packaging
has been updated accordingly, the libgdal-grass package was updated to
2.0.0 as well.

> 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.

There was a change of plans after further discussion in the gdal
transition bugreport, the alternative dependency template has been kept
and libgdal1h was renamed to libgdali (which Breaks/Replaces all
preceding libgdal1h versions). This should ensure that upgrading only
gdal won't break its reverse dependencies, the reverse dependencies must
be upgraded along with gdal because of the unstable C++ ABI.

> 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?

The Release Team also thought [1] we should transition to GDAL 1.11.2
first because that transition can be started now, we can then use
experimental to resolve any GDAL 2.0.0 issues in reverse dependencies.

The GDAL 2.0.0 packaging will only be available in git for the time
being for interested parties to build themselves.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756867#117

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1