Re: SpatiaLite 4.3.0 and the wider spatialite family
A few days ago spatialite & spatialite-tools 4.3.0-RC0 were released
along with spatialite-gui 2.0.0-devel and its librasterlite2 1.0.0-devel
dependency.
Both spatialite & spatialite-tools 4.3.0~rc0 have been uploaded to
experimental, but because spatialite has to pass NEW first
spatialite-tools cannot be built yet.
https://ftp-master.debian.org/new/spatialite_4.3.0~rc0-1~exp1.html
spatialite-gui no longer depends on the deprecated libgaiagraphics &
librasterlite libraries, now that it has switched to librasterlite2.
librasterlite2 1.0.0~rc0 is still in NEW, and we'll need to play some
tricks with the version number to have 1.0.0~devel succeed ~rc0.
https://ftp-master.debian.org/new/librasterlite2_1.0.0~rc0-1~exp2.html
On 05/29/2015 07:33 PM, Sebastiaan Couwenberg wrote:
> On 05/23/2015 02:15 AM, Sebastiaan Couwenberg wrote:
>> 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 [...]
>
> There has been no feedback from the Release Team about the gdal
> transition yet. Keep an eye on #756867 for progress.
>
> https://bugs.debian.org/756867
We're ready for the gdal transition, but the mapnik 3 FTBFS issues are
blocking it.
>> * 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.
>
> A patch has been added, but it's not enable yet to prevent having to
> pass the NEW queue again. The patch has also been forwarded upstream.
>
> http://anonscm.debian.org/cgit/pkg-grass/spatialite.git/tree/debian/patches/14-soversion.patch?h=experimental
The patch was incorrectly applied upstream, the - from the -version-info
option was missing causing the SOVERSION to decrement to 0. The updated
patch has been forwarded upstream too along with all remaining patches, see:
https://groups.google.com/d/msg/spatialite-users/oAzONsvEK08/rjzErEKVsuUJ
https://groups.google.com/d/msg/spatialite-users/kIZA-n4f9kk/IoaxSGjUWZEJ
>> 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.
>
> There won't be a final SpatiaLite 4.2.1 release, because of the many
> changes accumulated in the upstream repository. SpatiaLite 4.3.0 will be
> released as soon as possible instead. See:
>
> https://groups.google.com/d/msg/spatialite-users/Xk7o4h1Iss8/1RjjtJkyCEwJ
I don't expect any new issues with the Spatialite 4.3.0 changes since
4.2.1, but I'll do new round of rebuilds to verify this.
It looks like we'll be ready for the spatialite transition soon after
the final 4.3.0 release.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: