[GRASS-dev] GRASS 6.3.0 to be released

[Michael Barton]

Marco,

I see what you mean on Windows. Actually, in this case, there are no
dependencies like you find on Unix systems. A separate install for
Msys/TclTk/Python might be useful. Then that part could be installed only as
needed and GRASS could be updated more often.

Michael


On 4/16/08 9:00 AM, "grass-dev-request at lists.osgeo.org"
<grass-dev-request at lists.osgeo.org> wrote:

> Date: Wed, 16 Apr 2008 17:18:30 +0200
> From: <marco.pasetti at alice.it>
> Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
> To: "Moritz Lennert" <mlennert at club.worldonline.be>
> Cc: Martin Landa <landa.martin at gmail.com>, Glynn Clements
> <glynn at gclements.plus.com>, GRASS developers list
> <grass-dev at lists.osgeo.org>
> Message-ID:
> <FA8A693893F4CE4283B4473C79FA47D505BB4184 at FBCMST06V02.fbc.local>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Moritz,
>  
>> This actually sounds much more sophisticated than what Glynn proposed.
>  
> yes, it is... but we could make a walkaround... I'll explain how later...
>  
>> Could you not simply propose one installer with only the latest
>> (complete) GRASS binaries. This installer could check for any existing
>> installation of GRASS and propose to erase that before installing the
>> new version, or install the new version next to the old.
>  
> very good ;-) we are at the same *point* here. I already thought it some weeks
> ago, before ro release RC6... and that's why I already added in RC6 installer
> some registry key values that would let me the job (that is: let future
> installers recognise if GRASS is already istalled on the system, what version
> and where). I already talked with Markus about this option in future WinGRASS
> installers.
>  
>> The question then is: do we need a "complete" installer with everything
>> in it (as you suggest), or can we impose the burden of two installers on
>> people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
>> installer. I think this would be the best solution for us, but it would
>> mean that at least for the first installation, users will have to
>> install two packages. If the GRASS installer could test for the
>> installation of the other package and propose to download it and lauch
>> its installation autmagically, then this might be the best solution.
>  
> what do you mean about *dependencies*? the only dependencies that are
> indipendent to GRASS binaries is Python!
> all the other DLLs are necessary to start GRASS. What would happen if we
> release GRASS with an additional support (jpeg, for example) not previously
> supported? we must provide the libjpeg with the installer, or update the
> *dependencies installer*?
> IMHO, this is a sctrictly UNIX way to think... windows is very different: if
> you release binaries, you must provide all the DLLs needed by those binaries
> along with them.
> It would be a *safer* solution to release future WinGRASS installers along
> with a separated updater: in that way new users would install the whole GRASS
> package (why provide 2 different installers when users absolutely need to
> install both GRASS bins and Deps?) or simply download and lunch a smaller
> updater, that would copy/replace only the new bins and libs.
>  
> BTW, I still think that providing separated installers for GRASS and its
> dependencies is a nonsense...
>  
> Best regards,
>  
> Marco

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton