[GRASS-dev] GEM Wizard question

Benjamin Ducke benjamin.ducke at ufg.uni-kiel.de
Tue May 22 03:01:48 EDT 2007


Actually, it's not much of a problem to introduce a new default and/or
optional install prefix in GEM. The real trouble lies in two different
areas, as far as I can think of right now:

1. The HTML man pages for the newly installed modules should be
integrated into main HTML index. Currently, GEM manipulates the main
HTML index in the install dir to do so. Of course, this requires
superuser rights. The ideal solution would be to have a placeholder in
the global HTML frontpage that will point to a subindex page present in
the user's local extension directory. No idea how to do that in HTML

2. Many people like to have new GUI menu entries in gis.m when they
install additional modules. This means that gis.m has to be prepared to
look for additional menu entries in the current user's extension
directory. This should not be too hard to do.

In principle, I agree that it would be much better to have locally
installed extension. This could simplify the logics behing GEM a lot,
too. It would also be possible to keep both the global and local
installation schemes side-by-side, as a system-wide extension management
would probably also have its merits.

Benjamin

William Kyngesburye wrote:
> I've been meaning to ask about this root/external mod issue - is there
> any plan to support installation of GEM modules in a user dir?  More
> than just a problem of HOW to run this as root in the GUI, it's also a
> bit of a security problem and a platform standardization issue.
> 
> On OSX, installing extras into an application binary is not the way
> things are done.  They should be installed in a standard
> plugin/extension location for the application - /Library so it is
> globally available to users, or ~/Library to make it available only for
> a single user.
> 
> These locations act as extra GIS_BASEs, in effect - they have bin, lib,
> etc, doc... subfolders.  By use of standard GRASS env vars, they are
> easily included into the GRASS environment, and I recently added similar
> env vars and functions to locate external etc/ support files for modules
> that need it.
> 
> For the OSX application build I've set
> [~]/Library/GRASS/$version/Modules as the global/user locations.  For
> now I have a separate module build template, much like GEM, but built
> modules must then be manually copied to one of these locations, since
> I'm too lazy to figure out alternate install targets in the makefiles.
> 
> It would be nice to have GEM able to install in these locations at
> least, if not also arbitrary locations.  We would need to figure out
> good standard locations for other platforms also.
> 
> 
> On May 21, 2007, at 5:53 AM, Maris Nartiss wrote:
> 
>> Hi,
>>
>> I'm not following GEM development and thus have two silly questions:
>> 1) isn't possible to install additional modules via GEM into user's
>> home directory (as option)? Thus it could be made as easy as
>> installing some addons to Firefox.
>> 2) if getting superuser support for GUI right is lot of work, could
>> some GUI wizard just generate some commandline expression that could
>> be just pasted into terminal by user as last step to run it via su or
>> sudo?
>>
>> Just my 0.02.
>> Maris.
>>
>>
>> 2007/5/21, Benjamin Ducke <benjamin.ducke at ufg.uni-kiel.de>:
>>> I guess it wouldn't be too much trouble. GEM already has all that's
>>> needed for this: zipped extension packages can be downloaded (using
>>> wget), unzipped (to system's temp dir) and installed automatically.
>>> There is just one catch: since all files are installed into system-wide
>>> locations, the wizard will probably need superuser rights. So a tcl/tk
>>> based install wizard needs to provide a way to get the superuser
>>> password and run system commands with elevated rights.
> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
> 
> "History is an illusion caused by the passage of time, and time is an
> illusion caused by the passage of history."
> 
> - Hitchhiker's Guide to the Galaxy
> 
> 
> 
> 

-- 
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg




More information about the grass-dev mailing list