[Live-demo] Spatialite on version 6.0

[Hamish]

Micha wrote:
>  Spatialite - like many projects - is moving along faster than the
>    package maintainers can repackage. The components of the
>    spatialite stack available for Ubuntu from the repos are nearly a
>     year old,

for the sake of devil's advocate, another way of looking at it is
that they have had nearly a year's worth of QA testing and time to
mature.

> and some are not available yet at all (the new "readosm"
>     tool and the library to connect to xls files).
>    Previously, in 5.5 we had one package, spatialite-bin, and a few
>     other pieces compiled in. Even then we were installing older
>     versions.
>   I've put together a new install_spatialite.sh script [1] which
>     downloads and compiles the whole spatialite suite. It seems to be
>     working well on a VM of the alpha1 build that Angelos has
>     prepared. Before I suggest to push it into the build scripts, can
>      others have a look, and try it out so the bugs surface?
>    One caveat: to build all the components of the suite requires
>      several dev packages that are not part of the default xubuntu
>      distro. I install them all as part of the script, and this totals
>      to around 20 MB of disk space. And worse, some of the spatialite
>      components need a c++ compiler, also not part of xubuntu by
>      default. When I install g++ we take a hit of another ~25MB of disk
>      space.  I guess I should add a apt-get purge for all these
>      additional development packages after the builds are done to
>     recover disk space?

certainly 'apt-get remove' anything that you used that is not needed at
run time, but it is worth checking that you are not forcibly removing
a package that another script depends on. (some do depend on -dev pkgs)


It is highly preferable to not build from source in the install script,
but rather to cut your own packages based on the newer code for cases
when the official ubuntu package is too far out of date. I'm sure that
one of the several ppa's would be happy to host the package, and it could
be helpful to those doing the upstream packaging "for real".

The first attack point should always be to work towards getting the
upstream packaging done, everything else then flows automatically and
easily from that once it is in place. Often it is just minor changes to
the existing debian/ control and rules files to adapt the old packaging
rules to the new version of the software. We (here/UbuntuGIS/DebianGIS)
can help with advice if you get stuck/don't know where to start.


thanks,
Hamish