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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
