[Live-demo] 6.0 alpha4 Status

Angelos Tzotsos gcpp.kalxas at gmail.com
Sun Jun 17 12:57:37 PDT 2012

On 06/17/2012 10:21 PM, Micha Silver wrote:
> On 06/17/2012 12:39 PM, Angelos Tzotsos wrote:
> >  On 06/17/2012 01:57 AM, Hamish wrote:
> >>  Angelos wrote:
> >>  ...
> >>>  since there are not many things fixed from alpha3.
> >>>
> >>>  Thoughts
> I'd like to raise the question of spatialite versions again, before feature
> freeze. I don't want to be a nudnik on this, but the current mix of versions is
> not so good.
> By way of reminder: On OSGeo Live 5.5 we have the spatialite libraries and the
> CLI program installed from deb packages from the ubuntugis repos. In addition we
> installed the GUI programs (spatialite-gui and spatialite-gis) using
> pre-compiled binaries from the gaia-gis site. Back then we had version 3.0beta
> of the CLI program and ver 1.4 of the spatialite-gui.
> The current install_spatialite.sh script on 6.0 gets *everything* from the
> ubuntugis repo.  This leaves us with a newer version of the CLI program, 3.0
> stable, (the deb package "spatialite-bin") and recent versions of the
> libspatialite and librasterlite. However the most recent deb package for the GUI
> spatialite-gui is version 1.3 - quite old.  In fact a DB created from the
> command line (the newer version), with spatial indexes, *will not work* in this
> older GUI program since it lacks support for some new features!  So we're
> supplying two components of the same software suite that are incompatible. Not
> good...
> On the DebianGIS maillist there's been some productive discussion about
> spatialite - as Hamish pointed out recently. They have made good progress with
> the CLI package, and we now have a recent, stable libspatialite and
> spatialite-bin. But there are still dependency issues with the GUI program.
> We could just download the intermediary 1.4 version like we did for Live 5.5.
> But wouldn't it make more sense to grab the tarball for the latest version 1.5
> of spatialite-gui and compile it as part of the install script? This would give
> us 80% of the suite from debs and only the GUI program self-compiled. And the
> packages would all be of the same generation.
> And, of course if a newer deb for the GUI component comes out before our final
> release, it will be easy to change the install script to use it instead of the
> compilation.
> Regards,
> Micha
> -- 
> Micha Silver
> GIS Consultant, Arava Development Co.
> http://www.surfaces.co.il
Yes I believe this is a good suggestion.
I agree to have this mixture of compiled and pre-packaged binaries, it 
is better than having unstable or outdated non working versions.
But I have to ask:
Why is there a problem with dependencies in UbuntuGIS and we won't have 
the same when compiling the GUI part from source?


Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens

More information about the Osgeolive mailing list