Windows Installer RC

[Duncan Coutts]

On Sat, 2009-05-02 at 14:57 +0100, Claus Reinke wrote:

> Could you please provide some details about what the default
> installation mode will do to the system settings or registry, so that
> people can make an informed choice about which installation mode
> to use? File types used, associated actions, default actions, PATH
> settings, other settings (?), what happens to existing settings, how
> does the installer integrate with existing installations of GHC, Cabal,
> WinHugs, ...?

What kind of integration do you mean? What is it you would be looking
for or looking to avoid? You've mentioned previously the issue of
"stealing" file extensions etc. That'd be a good one to test. Is there
anything else?

> Btw, is GHC the only implementation currently included in the HP?

Yes.

There is of course nothing stopping hugs or nhc98 releases from using
the same set of library versions and it would be great if they do so.

> >    * glut32.dll is not included, though it probably should be.
> 
> While this is consistent with the last GHC installers that did provide
> GLUT at all, those had seen a steady increase in we-want-to-get-rid-of-this
> by GHC HQ even before the Haskell Platform initiative was announced,
> and when the HP appeared on the horizon, the idea became that "the HP
> will address this properly, so we don't have to". So it isn't a good idea
> to take a lead from recent GHC installers, as far as GLUT is concerned.
> 
> The earlier installers (provided by Sigbjorn via unknown means;) were
> more complete, but the later installers (using automated installer generation)
> often suffered from missing packages or missing package components
> (when the installer builder's machine didn't have glut installed, GLUT
> wouldn't be built, so not included at all, and even if glut was installed,
> glut32.dll would usually be in a place from which the installer builder
> wouldn't copy it until told to do so explicitly).
> 
> I've always had difficulties understanding the advantage of providing
> GLUT in an incomplete and unusable form (glut32.dll is some 200K
> uncompressed, GLUT can't be used without it, and the dll is from the
> same non-Haskell package that provides glut.h as well, so why include
> one but not the other?). Finding and adding a dll is easier than building
> the package, but for a Haskell Platform release this is bordering on the
> ridiculous, isn't it?-)

The problem, as you well know, is that there is nowhere sensible to put
a glut32.dll file. It's bad practise to put .dll files in the windows or
system directories. Putting it somewhere on the %PATH% sometimes works
but is fragile.

> If it is a question of location, put it in a non-active directory, to be
> moved (as I've been doing on my system) where Cabal installs its
> executables. That would avoid installing any files outside the HP
> root directory while still providing a complete package.

That doesn't help it to "just work" and it doesn't help people making
random .exe files in random directories.

> Of course, it is up to the person doing the work to decide, but I
> thought I'd make a last attempt to persuade you!-) Either way, thanks
> for your efforts!

Solving the Windows dll problem properly requires more thought and more
work I fear (personally I think assemblies will be the way to go). I'm
not terribly keen on the temporary solutions that force the users to
read lots of text and work out what to do themselves (it's ok for you
because you know what you're doing).

In practise for the specific case of the glut32.dll, it seems like not a
great problem because most users have it already (from their graphics
driver). If the ghc installer has gotten away with it for so long then
we can get away with it for a little longer.

For the next release we can talk more about a least bad interim
solution.

> A general comment (not windows specific): since OpenGL/GLUT
> were dropped -in premature anticipation of HP's arrival- from the
> GHC installers long ago, it would have been good to communicate
> with the hopengl mailing list on the OpenGL/GLUT-specific aspects
> of the Haskell Platform.
> 
> There had been quite a few patches piling up there, of which the HP
> organizers haven't been aware, and I doubt that many of that list's
> readers are aware of how the details of the HP process will affect
> them. They have been waiting under the assumption that the HP
> will fix their packages so that things will "just work" again, for them
> and their clients.

Right, we should have communicated better. We should have made it clear
that the HP doesn't do package releases, that we expect to pick up
releases made by the maintainers. We were under the assumption that the
GL packages that have been available on hackage for the last 6 months
were ok and usable. I'm sure that they are perfectly usable, but in any
case there is the opportunity to pick up the new bug-fix releases in the
next minor HP release. So no major disaster :-)

Duncan