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, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Date: Wed, 16 Apr 2008 17:18:30 +0200 > From: <[EMAIL PROTECTED]> > Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released > To: "Moritz Lennert" <[EMAIL PROTECTED]> > Cc: Martin Landa <[EMAIL PROTECTED]>, Glynn Clements > <[EMAIL PROTECTED]>, GRASS developers list > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
