Re: [DebianGIS] [ gpsdrive ] problems with manual build on Etch
> > You might want to try if the current version would compile for etch.
> > Maybe you can give us some hints what to change in order to be able to
> > compile on etch and testing.
Gpsdrive from svn compiles fine for me on etch as long as I
--disable-mapnik. I wouldn't worry too much about testing, it'll sort
itself out if we do a good job on the sid package, and anyway is a
moving target.
> Andreas Putzo wrote:
> I did a little testing and as far as i can tell the only thing missing
> for etch is mapnik. Thus i created a backport for it and after
> installing it builds for me.
>
> These build-depends were missing:
> libart-2.0-dev
> libfile-slurp-perl (?)
Added to DEVPACKAGES and scripts/devpackages-debian.sh in SVN, but didn't
touch anything in the (upstream) debian/ dir.
> libqt4-dev
>
> The planet.osm.sql.bz2 mentioned in install-mapnik-osm.txt needs
> postgresql-8.2 while the version in etch is 8.1.
> But creating the database using osm2pgsql works. That's actually the
> first time i run gpsdrive using mapnik to render the tiles on the fly.
> Works great :-)
>
> gpsdrive_mapnik_gentiles.py (and propably others) wants to use python2.5.
> On etch the dependency on python installs python2.4. So it should use
> either a versioned dependency or the scripts should be modified to use
> /usr/bin/python if this is possible (didn't check this).
In light of all that, and a preference for keeping backports as minimally
invasive as possible, I'd prefer to see a stand-alone backport for etch
without Mapnik support which doesn't need any other backported components.
I accept that Mapnik/OSM support is really cool and lots of folks will
want to use it... perhaps package two versions? One simple, one kitchen
sink.
?,
Hamish
Reply to: