R: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
Hi all, When do you think that 6.3.0 will be released? Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: R: [GRASS-dev] GRASS 6.3.0 to be released
Glynn, I would suggest two installers: one for GRASS alone, and one for the various dependencies (PROJ, GDAL, MSys, ...). The idea is that you shouldn't have to download all of the dependencies each time a new version of GRASS is released. we could do as follows: 1. a *complete*, *first time* GRASS installer, based on latest release, with all the dependencies built-in 2. and *updater*, installed along the *first installation*, that check the WinGRASS repository looking for last GRASS updates, and download/install only the latest updated files (both for GRASS and dependencies). It would be not an easy work, but I think that I'll can do it... even if not very soon :-) Marco Da: Glynn Clements [mailto:[EMAIL PROTECTED] Inviato: mer 16/04/2008 10.20 A: Moritz Lennert Cc: [EMAIL PROTECTED]; 'Martin Landa'; 'GRASS developers list' Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released Moritz Lennert wrote: It would be good also for me, even if it would better if we release it on next week tough (I'm very busy now). BTW, there are few thing to do for me, just some improvements for windows installer... Martin, do you think that we could add the needed python files into the 6.3.0 windows package, in order to let users start the pyGUI without the need to install python stuffs by themselves? -1 I don't think we should bloat the installer with everything that people might need. It really is not difficult to download and install the python installers... I would suggest two installers: one for GRASS alone, and one for the various dependencies (PROJ, GDAL, MSys, ...). The idea is that you shouldn't have to download all of the dependencies each time a new version of GRASS is released. An ideal solution would be to use Cygwin's Setup utility, but I don't know how much work would be involved. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released
I would vote for a lean base installer to be distributed on grass.itc.it. Other projects can build fatter installers based on that and distribute them. A bare bones installer will be much easier to maintain for us in the long run. Benjamin Moritz Lennert wrote: On 16/04/08 10:41, [EMAIL PROTECTED] wrote: Glynn, I would suggest two installers: one for GRASS alone, and one for the various dependencies (PROJ, GDAL, MSys, ...). The idea is that you shouldn't have to download all of the dependencies each time a new version of GRASS is released. we could do as follows: 1. a *complete*, *first time* GRASS installer, based on latest release, with all the dependencies built-in 2. and *updater*, installed along the *first installation*, that check the WinGRASS repository looking for last GRASS updates, and download/install only the latest updated files (both for GRASS and dependencies). It would be not an easy work, but I think that I'll can do it... even if not very soon :-) This actually sounds much more sophisticated than what Glynn proposed. 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. 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. But you're the one doing the work, so the ultimate decision will be yours ;-) Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Benjamin Ducke Senior Applications Support and Development Officer Oxford Archaeological Unit Limited Janus House Osney Mead OX2 0ES Oxford, U.K. Tel.: ++44 (0)1865 263 800 [EMAIL PROTECTED] -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
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 Da: Moritz Lennert [mailto:[EMAIL PROTECTED] Inviato: mer 16/04/2008 15.07 A: [EMAIL PROTECTED] Cc: Glynn Clements; Martin Landa; GRASS developers list Oggetto: Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released On 16/04/08 10:41, [EMAIL PROTECTED] wrote: Glynn, I would suggest two installers: one for GRASS alone, and one for the various dependencies (PROJ, GDAL, MSys, ...). The idea is that you shouldn't have to download all of the dependencies each time a new version of GRASS is released. we could do as follows: 1. a *complete*, *first time* GRASS installer, based on latest release, with all the dependencies built-in 2. and *updater*, installed along the *first installation*, that check the WinGRASS repository looking for last GRASS updates, and download/install only the latest updated files (both for GRASS and dependencies). It would be not an easy work, but I think that I'll can do it... even if not very soon :-) This actually sounds much more sophisticated than what Glynn proposed. 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. 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. But you're the one doing the work, so the ultimate decision will be yours ;-) Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: R: [GRASS-dev] GRASS 6.3.0 to be released
Hi Michael, If its 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 ;-) Marco _ Da: Michael Barton [mailto:[EMAIL PROTECTED] Inviato: mercoledì 16 aprile 2008 19.16 A: [EMAIL PROTECTED]; grass-dev@lists.osgeo.org Oggetto: Re: R: [GRASS-dev] GRASS 6.3.0 to be released You have described it well. If its 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, [EMAIL PROTECTED] [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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, [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 grass-dev@lists.osgeo.org 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
Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released
[EMAIL PROTECTED] wrote: I would suggest two installers: one for GRASS alone, and one for the various dependencies (PROJ, GDAL, MSys, ...). The idea is that you shouldn't have to download all of the dependencies each time a new version of GRASS is released. we could do as follows: 1. a *complete*, *first time* GRASS installer, based on latest release, with all the dependencies built-in 2. and *updater*, installed along the *first installation*, that check the WinGRASS repository looking for last GRASS updates, and download/install only the latest updated files (both for GRASS and dependencies). It would be not an easy work, but I think that I'll can do it... even if not very soon :-) I don't see much point in doing both. If you have #2, it makes #1 rather pointless. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: R: [GRASS-dev] GRASS 6.3.0 to be released
Moritz Lennert wrote: I would suggest two installers: one for GRASS alone, and one for the various dependencies (PROJ, GDAL, MSys, ...). The idea is that you shouldn't have to download all of the dependencies each time a new version of GRASS is released. we could do as follows: 1. a *complete*, *first time* GRASS installer, based on latest release, with all the dependencies built-in 2. and *updater*, installed along the *first installation*, that check the WinGRASS repository looking for last GRASS updates, and download/install only the latest updated files (both for GRASS and dependencies). It would be not an easy work, but I think that I'll can do it... even if not very soon :-) This actually sounds much more sophisticated than what Glynn proposed. 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. 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. I don't think that you even need to go that far. If downloading and running (in the correct order) two installers is beyond the user's abilities, chances are that they'll spend a couple of days flooding the grass-user ML with noob questions before giving up on GRASS altogether. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: R: R: [GRASS-dev] GRASS 6.3.0 to be released
[EMAIL PROTECTED] wrote: 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. Yes, but there's no need to re-install those same binaries every time a new version of GRASS comes out. GRASS (and especially WinGRASS) is a relatively unstable project. I would expect that several GRASS updates will be released before any of the dependencies need to be upgraded. 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. And the end result is commonly known as DLL hell, where every program tries to install a particular version of common DLLs, often breaking other programs which rely upon those DLLs. And whenever a security vulnerability is found in a library, you can't just replace the library; you have to replace a dozen complete applications (or, more likely, you just live with having hundreds of unpatched vulnerabilities). -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
