R: [GRASS-dev] GRASS 6.3.0 to be released

Wed Apr 16 13:16:10 EDT 2008

You have described it well. If it¹s easier to just do a single package, then
I think that is what you should do. That is what most Windows (and Mac)
users expect anyway.

Michael

On 4/16/08 9:40 AM, "marco.pasetti at alice.it" <marco.pasetti at alice.it> wrote:

> Michael,
>  
>> >I see what you mean on Windows. Actually, in this case, there are no
>> >dependencies like you find on Unix systems
>  
> thx. it's difficult to be a Windows user here. GRASS people is used to work on
> too much advanced systems than I'm used to ;-) (even if I'm a linux user too)
>  
>> >A separate install for Msys/TclTk/Python might be useful.
>  
> MSYS:
> -----------------------
> I think we could provide MSYS as install option or don't provide it at all...
> if people want MSYS they can download and install using the official MSYS
> installer (the GRASS installer could just check if MSYS is installed and
> create the grass63 file into /usr msys folder, according to selected GRASS
> install path, as it already does)
>  
> TclTk
> -----------------------
> This is needed, since GRASS is built with it and some binaries require tcl/tk
> DLLs. I think we must provide it along binaries
>  
> Python
> -----------------------
> I think that's the only indipendent package installer we could provide.
>  
>> >Then that part could be installed only as
>> >needed and GRASS could be updated more often.
>  
> I think that's not a *frequency* problem, but just a *weight* problem of the
> installers provided.
>  
> If I had built a new version of GRASS to release, it's not absolutely a
> problem for me to package all the other files along with it (I mean the new
> GRASS build) as I as did with the WinGRASS-6.3.0RC5 and RC6 releases. I need
> to just run an automated batch file I wrote for the job, and then compile the
> NSIS script to create the related installer. The whole packaging job takes
> approx 5 minutes!
>  
> I hope to have well described the *situation*
>  
> Best regards,
>  
> Marco
>  
> 
> 
> Da: grass-dev-bounces at lists.osgeo.org per conto di Michael Barton
> Inviato: mer 16/04/2008 18.15
> A: grass-dev at lists.osgeo.org
> Oggetto: Re: [GRASS-dev] GRASS 6.3.0 to be released
> 
> 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
> 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> 
> __________________________________________
> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20080416/3a2ea061/attachment-0001.html