Re: SpatiaLite 4.2.1 and the wider spatialite family
On 08/04/2014 03:36 AM, Sebastiaan Couwenberg wrote:
> As you may have seen I've update the spatialite and spatialite-tools
> packaging for the recent SpatiaLite 4.2.0 release.
In the mean time both spatialite & spatialite-tools has been updated to
4.2.1 RC1, and have been available in experimental for a while now.
Because of the spatialite_init() issue reported #785091 and discussed
elsewhere [1][2][3][4], I'd like to start the spatialite transition as
soon as possible but there are a number of prerequisites to be met first:
* Transition from GDAL 1.10.1 to 1.11.2 to get the
spatialite_init_ex() support in GDAL. GDAL 1.11 will use
spatialite_init_ex() for SpatiaLite >= 4.1.2.
Like SpatiaLite 4.2 we didn't get GDAL 1.11 into unstable in time
for the jessie freeze, so it's high time to restart the transition
(#756867) [5]. Because we don't have alternative symbols changes in
gdal 1.10.1 we can't rely on the libgdal.so.1-<version> dependency
to track the transition. How to best track the transition with ben
is still to be discussed with the Release Team. I think I have a
workable ben configuration, it can only not track bad packages [6].
* Fix the libspatialite SONAME to not decrement. One of the FTP
masters raised this issue before accepting the package into
experimental [7]. I'll forward the fix for inclusion in the final
SpatiaLite 4.2.1 release. The package will then have to pass NEW
again which is painfully slow since the freeze although it started
picking up speed again recently.
[1] https://bugs.debian.org/785091
[2] http://lists.osgeo.org/pipermail/qgis-developer/2015-May/037785.html
[3]
https://groups.google.com/d/msg/spatialite-users/v-RCCrx5GoM/qOJ678RIeVsJ
[4] http://lists.osgeo.org/pipermail/gdal-dev/2015-May/041806.html
[5] https://bugs.debian.org/756867
[6] http://linuxminded.nl/tmp/pkg-grass-transitions/html/libgdal1.html
[7]
http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-December/025980.html
> 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.
SpatiaLite 4.2.1-RC1 has the same issue as mentioned before. The SONAME
for SpatiaLite 4.2.0 was fixed, but for 4.2.1 current has so far not
incremented:
4.2.0: libspatialite.so.7 (version-info 7:0:0)
4.2.1-RC0: libspatialite.so.6 (version-info 7:0:1)
4.2.1-RC1: libspatialite.so.6 (version-info 7:0:1)
In RC0 8 symbols were added and none were removed, so current needs to
be incremented too to keep the SOVERSION at 7.
> 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.
While I changed my mind regarding the package name due to the lintian
complaints, in the end this stayed the same for 4.2.1 after all.
> 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.
As expected the transition didn't happen before the freeze. Now we have
about two years until the next freeze, so getting them into stretch
shouldn't be a problem.
Getting GDAL 1.11.x out of experimental will also make room for GDAL 2.0
(pre-)releases.
While I prefer to first do the spatialite transition because of its
limited scope, having to wait for the final release and passing NEW
again won't make that likely. After patching the SONAME issue in
spatialite 4.2.1~rc1 I'll get the gdal transition moving again.
I have considered reverting back to spatialite 4.2.0 for unstable, but
so far prefer to wait for the final 4.2.1 release. I may have to
reconsider this after the gdal transition.
> 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.
Not much has changed on this topic. I think librasterlite2 needs to be
finalized before spatialite-gui 1.8.0 can be released. Once it's
released we should be able to get rid of libgaiagraphics which has been
deprecated upstream along with librasterlite.
Unlike libgaiagraphics, librasterlite does have other reverse
dependencies (mapnik) so we should keep it around a little longer.
> New projects by Alessandro Furieri that we'll want to include in Debian
> GIS are librasterlite2 (to supersede librasterlite), LibreWMS, and
> dataSeltzer.
Both librasterlite2 and librewms have packaging available, but only
librasterlite2 has so far been uploaded. It's in NEW for a while now.
https://ftp-master.debian.org/new/librasterlite2_1.0.0~rc0-1~exp1.html
> Help with packaging these new projects, and the spatialite transition is
> much appreciated.
With the changes in spatialite (4.2.1~rc1-1~exp5) pyspatialite
successfully builds again, some private symbols are required for its
build. pyspatialite still needs to be ported to stop using the
deprecated spatialite_init() method, which will likely need to be
contributed because upstream doesn't look very active anymore.
There is not much left to do for the spatialite transition other than
what's mentioned above. All reverse dependencies now build successfully
with the latest version.
Transition: proj
libspatialite5 (4.1.1-10) -> libspatialite6 (4.2.1~rc1-1~exp5)
The status of the most recent rebuilds is as follows.
gdal (1.10.1+dfsg-8 / 1.11.2+dfsg-1~exp2) OK / OK
librasterlite (1.1g-5) OK
pyspatialite (3.0.1-6) OK
spatialite-tools (4.1.1-5 / 4.2.1~rc1-3) OK / OK
merkaartor (0.18.1-3) OK
qgis (2.8.1+dfsg1-1 / 2.8.2+dfsg-1~exp1) OK / OK
spatialite-gui (1.7.1-5) OK
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: