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

[Glynn Clements]

marco.pasetti at alice.it 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 <glynn at gclements.plus.com>