[GRASS-user] Ubuntu Packages for Addons [was: Re: Fwd: Re: ppa for grass 7 Ubuntu Quantal]

Hamish hamish_b at yahoo.com
Fri Apr 26 18:13:23 PDT 2013


Tim wrote:
> I question when looking at :
> http://trac.osgeo.org/grass/browser/grass-addons
> 
> I wonder:
> * why is there a separate branch per major grass version?

between grass 5, 6, and 7 the library APIs change and the
module options/flags change, so a module written for one
often won't work on another without some slight modification.

> * what is the policy for backwards / upwards compatibility?

within major version backwards compatibility. A module written
for 6.0.0 will still work with any future 6.y.z versions.

It is likely for compiled modules the ABI is not stable, and
you will have to recompile for the current version. Any python
and shell scripts should be forward-compatible though. If you
try to run a compiled addon module against a different libgis
than the one it was built for, you will get the "please untangle
versions" error. "g.version -r" shows the libgis rev for this
reason:

g.version -r: Print the GIS library revision number and time

GRASS 6.4.1 (2011) 
Revision: 43636 
Date: 2010-09-22 22:18:42 +0200 (Wed, 22 Sep 2010) 


GRASS 6.4.2 (2012) 
Revision: 45934 
Date: 2011-04-13 13:19:03 +0200 (Wed, 13 Apr 2011) 


GRASS 6.4.3svn (2013) 
Revision: 50937 
Date: 2012-02-26 02:14:51 +1300 (Sun, 26 Feb 2012) 


GRASS 6.5.svn (2013) 
Revision: 50936 
Date: 2012-02-26 02:14:47 +1300 (Sun, 26 Feb 2012) 


it doesn't change very much, but often enough to mean that
you need to recompile your addons when switching between minor
versions. (e.g. it's been more than a year since it changed
last)


> * shall we instead of grouping by command type group by
> version?

an addon package containing grass7 addons should exclusively
depend on the grass7-core package etc. so at minimum it must
be grouped by major version.


Hamish:
> > and install to /usr/lib/grass64/addons/. We'd have to
> > patch our lib/init/init.sh in the main ubuntu package
> > to add that dir to the GRASS_ADDON_PATH if it existed
> > on the system.
Tim:
> Why do we not make this default, then?

because Debian installs grass in a funny place (/usr/lib/grassXY),
any system packages need to be available to all users equally-
so in a common OS dir, and personal addons can't go into a
system dir where the user does not have write access.
It's not a big deal to do the patch.


regards,
Hamish


More information about the grass-user mailing list