Windows Installer RC

[Mikhail Glushenkov]

Hi Claus,

Claus Reinke <claus.reinke at ...> writes:

> Pre Cabal, ghc installations were *relocatable* (no hardcoded absolute
> paths, everything relative to where ghc is). Some of us have occasionally
> used that to run ghc from a usb drive or a network-mounted directory
> when giving presentations with demos on someone else's machine (eg,
> the one installed in a lecture theatre).

You raised a valid point here. It's too late to add new features
now, but the next release will install everything relocatably.

> "extralibs"? I thought those were gone, eg., the platform would just be
> a pre-populated ghc installation, with nothing to distinguish former extralibs
> from packages installed later 

I prefer to separate "standard GHC" and platform packages.

> (actually, given that structure, all packages,
> including those added later, will be installed under "extralibs", right?).

The "extralibs" directory contains additional packages that are
not part of the base GHC install.

If you mean packages added by cabal-install, they'll be installed
to $PROGRAMFILES\Haskell.

> > By default, the installer:
> >
> >   1. Unpacks all files to the specified location (mandatory)
> >
> >   2. Updates packages.conf (mandatory)
> 
> That is the packages.conf that comes with the ghc being installed by
> the same installer, right? So it doesn't change any existing databases, just
> makes sure that the newly installed ghc knows about its initial population
> of packages.

Yes, of course.

> Thanks, that is almost readable. So you're actually removing
> the $PLATFORMDIR explicitly from package.conf,

Not quite - @PLATFORMDIR@ in package.conf is replaced with the
full pathname of the "extralibs" directory.

> If I read this correctly, it still doesn't follow the conventions we have
> tried to agree on for years, and will not cooperate with, eg, WinHugs,
> or previous settings. See separate answer to Duncan's question in this
> thread for details and examples that illustrate what I mean by installer
> ping pong.

Yes, for now we just mimic the GHC's installer behaviour. This'll
be changed in the next release to cooperate better with WinHugs
and the like.

> Not to be misunderstood: this sounds quite promising, especially the
> "(optional)" but bugs have had subtle causes in the past, so I'd like a
> clear and detailed specification, something like the above, and it should
> be linked from the HP release page, right next to the location of the HP
> installer.

Thanks, a very good suggestion! I'll write and implement a
specification based on the documents you linked to for the next
release.

> >> what happens to existing settings,
> >
> > File associations are not currently backed up, though the
> > uninstaller won't delete them if they weren't modified during
> > installation.
> 
> So I'd lose them in the standard installation mode.

With the current installer, yes.

> You're already including part of the same third-party C library,
> namely glut.h. So you're deliberately breaking the package you're
> installing by removing an essential component, and you're not even
> including that missing component, so your users will have to hunt for
> it on the web. Not my choice, not a decision I can understand, but
> not my decision to make.

Sure, this is not the best possible behaviour, but that's what
was agreed on for now. We'll have to come up with a better
third-party C library policy eventually.

> I also noticed that you're using HKCR, where I'd have expected
> HKLM or HKCU (cf. http://hackage.haskell.org/trac/ghc/ticket/2489 ),

HKCR is what the GHC installer uses for file associations. You're
probably right that HKLM should be used instead, though. I'll
look into it later.

> or the SHCTX listed in NSIS docs "4.9.2.17 WriteRegExpandStr"

IIRC, SHCTX is needed when you install only for the current user,
which is not yet implemented.

Overall, thanks for the suggestions, your feedback is very
helpful!