SpatiaLite 4.2.0 and the wider spatialite family
As you may have seen I've update the spatialite and spatialite-tools
packaging for the recent SpatiaLite 4.2.0 release.
I've been working on the spatialite packaging since RC1, in which an
unexpected SONAME bump was used.
The SONAME interestingly decremented from 5 to 4 instead of incrementing
to 7:
4.2.0: libspatialite.so.4 -> libspatialite.so.4.2.0 (version-info 6:0:2)
4.1.1: libspatialite.so.5 -> libspatialite.so.5.1.0 (version-info 6:0:1)
4.0.0: libspatialite.so.5 -> libspatialite.so.5.0.1 (version-info 5:1:0)
3.0.0: libspatialite.so.3 -> libspatialite.so.3.0.0 (version-info 3:0:0)
3 symbols were removed (made private), and 99 added. So the proper
version-info should be 7:0:0 according to the libtool versioning. I
asked upstream about this on the spatialite-users list, and this was
subsequently fixed.
The 4.2.0 release also builds the loadable extension module,
mod_spatialite, for which binary package libsqlite3-mod-spatialite has
been created. This should allow the use of SpatiaLite with
load_extension('mod_spatialite') without linking to libspatialite.
Like GDAL 1.11.0, SpatiaLite 4.2.0 adds support for GeoPackage, but I'm
afraid we won't be able to transition from 4.1.1 to 4.2.0 before the
freeze. I seriously doubt I'll have enough time to verify the reverse
dependencies and get a transition slot from the Release Team before
November.
spatialite-gui 1.8.0 is not out yet, which we most likely want to
include in the spatialite 4.2.0 transition. And I'm not sure when the
release is expected.
New projects by Alessandro Furieri that we'll want to include in Debian
GIS are librasterlite2 (to supersede librasterlite), LibreWMS, and
dataSeltzer.
Help with packaging these new projects, and the spatialite transition is
much appreciated.
Kind Regards,
Bas
--
GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: