[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@lists.osgeo.org"
<grass-dev-request@lists.osgeo.org> wrote:

Date: Wed, 16 Apr 2008 17:18:30 +0200
From: <marco.pasetti@alice.it>
Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
To: "Moritz Lennert" <mlennert@club.worldonline.be>
Cc: Martin Landa <landa.martin@gmail.com>, Glynn Clements
<glynn@gclements.plus.com>, GRASS developers list
<grass-dev@lists.osgeo.org>
Message-ID:
<FA8A693893F4CE4283B4473C79FA47D505BB4184@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 :wink: 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

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 :wink: (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@lists.osgeo.org per conto di Michael Barton
Inviato: mer 16/04/2008 18.15
A: grass-dev@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@lists.osgeo.org
grass-dev-request@lists.osgeo.org wrote:

Date: Wed, 16 Apr 2008 17:18:30 +0200
From: marco.pasetti@alice.it
Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
To: “Moritz Lennert” mlennert@club.worldonline.be
Cc: Martin Landa landa.martin@gmail.com, Glynn Clements
glynn@gclements.plus.com, GRASS developers list
grass-dev@lists.osgeo.org
Message-ID:
FA8A693893F4CE4283B4473C79FA47D505BB4184@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 :wink: 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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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@alice.it” marco.pasetti@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 :wink: (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@lists.osgeo.org per conto di Michael Barton
Inviato: mer 16/04/2008 18.15
A: grass-dev@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@lists.osgeo.org
grass-dev-request@lists.osgeo.org wrote:

Date: Wed, 16 Apr 2008 17:18:30 +0200
From: marco.pasetti@alice.it
Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
To: “Moritz Lennert” mlennert@club.worldonline.be
Cc: Martin Landa landa.martin@gmail.com, Glynn Clements
glynn@gclements.plus.com, GRASS developers list
grass-dev@lists.osgeo.org
Message-ID:
FA8A693893F4CE4283B4473C79FA47D505BB4184@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 :wink: 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@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

Hi Michael,

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.

…and that’s very good to hear for me :wink:

Marco


Da: Michael Barton [mailto:michael.barton@asu.edu]
Inviato: mercoledì 16 aprile 2008 19.16
A: marco.pasetti@alice.it; grass-dev@lists.osgeo.org
Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released

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@alice.it” marco.pasetti@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 :wink: (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@lists.osgeo.org per conto di Michael Barton
Inviato: mer 16/04/2008 18.15
A: grass-dev@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@lists.osgeo.org
grass-dev-request@lists.osgeo.org wrote:

Date: Wed, 16 Apr 2008 17:18:30 +0200
From: marco.pasetti@alice.it
Subject: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
To: “Moritz Lennert” mlennert@club.worldonline.be
Cc: Martin Landa landa.martin@gmail.com, Glynn Clements
glynn@gclements.plus.com, GRASS developers list
grass-dev@lists.osgeo.org
Message-ID:
FA8A693893F4CE4283B4473C79FA47D505BB4184@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 :wink: 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@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