[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