Re: GDAL 1.11.4/2.0.2
Regarding the circle dependencies, we just had a discussion on #postgis IRC
and a potential solution would be for GDAL not to directly link to spatialite.
GDAL only depends on 3 spatialite symbols (the rest of the dependency is done
through SQL) : spatialite_init_ex() (spatialite_init() for ancient versions),
spatialite_cleanup_ex() (spatialite_shutdown() for ancient versions) and
So potentially GDAL could call them through dlopen() / dlsym() symbol loading,
similarly to what is done with the dependency to proj (actually GDAL supports
both standard linking mode and dynamic linking). The annoying thing is that
you must know the name of the shared object. On Linux "libspatialite.so".
Mac: "libspatialite.dylib" likely. On Windows, I guess the name depends on
whether spatialite is compiled with MSVC, mingw or cygwin
I might have a look at implementing that during the OSGeo code sprint.
> On 05-02-16 16:28, Johan Van de Wauw wrote:
> > On Fri, Feb 5, 2016 at 3:22 PM, Sebastiaan Couwenberg wrote:
> >> GDAL 1.11.4 & 2.0.2 have been released, but unfortunately we're not able
> >> to transition to GDAL 2.0 yet. Upstream would like everyone including
> >> Debian & Ubuntu to adopt 2.0, as would I. We mostly need the Fiona 1.7
> >> release which is not expected until March. 
> > The packaged version of fiona is not widely used. I don't think it
> > should stop us moving towards gdal 2.
> Thanks for the feedback. We can raise the severity of #802808 to serious
> when the transition to GDAL 2.0 starts. That will get it out of testing
> and unblock the gdal transition.
> > If I'm not mistaking, the patches to build with GDAL 2 already exist,
> > so perhaps we can do an upload of that version to experimental (and
> > remove from sid).
> The initial GDAL 2.0 changes for fiona are available in #802808, but
> upstream has changed the GDAL 2.0 support in final changes included the
> upstream repository. And those changes are entangled with other changes
> for Fiona 1.7 in the master branch. See:
> > A bit unconventional, but I think in this case the advantage of moving
> > towards GDAL2 are larger than sticking to fiona in sid/stretch.
> We're too late to get either 1.11.4 or 2.0.2 into Ubuntu xenial before
> the DebianImportFreeze on February 18th, but we may be able to get it
> into stretch before the freeze in November if you don't have to wait for
> I hope the move to GDAL 2.0 doesn't expose any serious issues with the
> reverse dependencies, as we won't have much time to get fixes for those
> into stretch too.
> The biggest blocker for the next gdal transition has been removed. I've
> just uploaded spatialite (4.3.0a-5) without the dependency on liblwgeom
> to untangle the spatialite->postgis->gdal->spatialite circular dependency.
> Kind Regards,
Spatialys - Geospatial professional services