[GRASS-user] Using g.extension on Ubuntu 11.04

[Hamish]

> > Glynn wrote:
> >> Modify the g.extension script to use sudo rather than "su -c ...".
Hamish:
> > I've already done that. Try the -u flag.
Markus:
> I have drastically simplified g.extension to two lines, being
> a wrapper for the way better g.extension.py which is included
> in the wxGUI of 6.4 and 6.5.

is it way better? How? Why?

I really doubt it because the main problems with g.extension have
nothing to do with the programming language or programmer's ability,
and are common to both.


the main structural problems with it are:

- ill/dual-defined use of GRASS_ADDON_PATH as both a /usr/local/bin
substitute and a /usr/local prefix. William has also implemented a
partial solution to that on OSX some time ago.

- different systems will have different ways of authorizing administration
permissions. on linux there is su and sudo in the wild, on OSX there is
sudo and a $USER's personal Library, on MS Windows there are other
layers... getting this right on all permutations and combinations will
take time.

- to install system wide or per-user?

- gcc/Makefile linking issues for C programs

- ... probably more but I'm in a rush right now (back in the office
next week)


> Find it attached. In my opinion there is not much point to
> continue to hack the shell version if the Python script
> does it much better. Of course you need Python being installed.

I need to research the python version more, but I don't understand how
it could magically solve the above problems, or what is fundamentally
broken the the existing shell version. I never really understood the
rationale for backporting the python version of it in the first place,
but I trust Martin to sculpt the wxGUI as he sees fit so don't mind it
there, even if keeping two live copies of the same thing in the same
release is inefficient to support.

most of g.ext is moving files around and running shell programs, which
is a natural thing to keep in a shell script.


> I didn't submit it yet to SVN.

Before we blast away any existing code, I'd like to know if there are
programming or structural problems in the shell version, if the python
version really solves these problems in a fundamentally better way, and
why the shell version can't use the same method. I am willing to put up
my time to fix the shell scripts if need be, but right now I'm not aware
of any problems which are not structural in nature, ie independent of
implementation language.


I would like to post a more constructive email, but I'm being pulled out
the door right now, and don't know of specific code problems that need
work so can't give a patch to fix it.


thanks for your patience,
Hamish