(changing lists from ubuntu@lists.osgeo.org and
grass-user@lists.osgeo.org to grass-dev)
On 14 July 2013 17:36, Rashad M <mohammedrashadkm@gmail.com> wrote:
I had added grass-addons repository on launchpad[1].
Hi, I wonder what is the right way to addons to the GRASS installation
and how then handle this in GRASS. If addons are handled by the
packaging system there is no point to handle these addons by
g.extension (this is how it works now if I understood correctly).
However, in this case addons are not listed in the Addons entry in the
Module tree in the Search modules tab in layer manager, since
currently only modules available during compilation (using generated
XML) and modules in .grass7/addons (using g.extension -a) are added to
this tree.
Hi, I wonder what is the right way to addons to the GRASS installation
and how then handle this in GRASS. If addons are handled by the
packaging system there is no point to handle these addons by
g.extension (this is how it works now if I understood correctly).
However, in this case addons are not listed in the Addons entry in the
Module tree in the Search modules tab in layer manager, since
currently only modules available during compilation (using generated
XML) and modules in .grass7/addons (using g.extension -a) are added to
this tree.
for a grass-addon package from e.g. the UbuntuGIS ppa, I'd suggest to
treat them as a "distribution toolbox" and so as any other new toolbox.
Then leave it up to the user to avoid re-downloading with g.extension.py.
I don't see much point in trying to maintain them in a addon xml registry;
or rather I still have a hard time understanding how such a registry
deals with the theoretical 50% of addon modules which are personal
scripts authored by the user and not in the grass repository. And
following that line of thought how a time-frozen selection of addon
modules from a PPA should co-exist with both user scripts and "live"
&/or updated addon modules direct from svn. Given all that grey area
the best I can suggest is to stay as flexible as possible, and so my
concern with the xml registry is that it can be quite brittle and so
fragile. :-/ but really I have no better idea to suggest. the self-
assembling freedesktop.org *.desktop menus + icon files used by Gnome/
KDE/Xfce/LXDE is one way to do it, but having worked with that a bit
making the custom menus for the osgeo live disc, I'd observe that it
works, but their way is rather abstruse and not very enjoyable to code.
You might also explore how GEM + gis.m organized this in GRASS 6 for
some ideas.
where does the ubuntu recipe install them on the disk now?
