Always create uninstaller

[jgbailey@…]

Some of the choices during install seem questionable - especially the choice to create an "uninstaller." It seems that should be automatic and not under user control.

[duncan]

Presumably the "Just unpack the files" option doesn't want to create an uninstaller. As I understand it, that option is supposed to be the moral equivalent of unpacking a .zip file. The "Just unpack the files" option is there due to popular demand from users who do not trust installers. Arguably we could move that option out and literally provide a .zip version and thus simplify the installer.

[anonymous]

Presumably the "Just unpack the files" option doesn't want to create an uninstaller.

Even unpacking files has to be undoable (though it is easy enough if all files are under a common root). There might be an issue in whether or not to register the uninstaller in the registry if the user has asked for an installation mode that doesn't affect the registry in any way, but this could be resolved (by documenting what is going on, so users know what -if anything- that choice is meant to accomplish, by simply creating an uninstaller without registering it, or by not creating an uninstaller if all that happens is that all files are unpacked under a common root).

As I understand the bug report, it says two things: (a) options offered aren't documented well enough for users to make informed choices and (b) an uninstaller is just the inverse of the installer, so once you've made your choices for the installer (eg, no meddling with registry or environment variables), you shouldn't have to make any additional choices for the uninstaller. Solving (a) would make it obvious that there is no unambiguous default for (b): "You've chosen unpack only. That means that no uninstaller will be registered, you can uninstall by simply removing <directory>.". This violates the expectation that installers should register uninstallers, but then the software won't be "installed", just unpacked, in that mode, so it might be fine, if explained.

As I understand it, that option is supposed to be the moral equivalent of unpacking a .zip file. The "Just unpack the files" option is there due to popular demand from users who do not trust installers. Arguably we could move that option out and literally provide a .zip version and thus simplify the installer.

Providing a .zip might be useful, but that *must not* remove the "unpack only" option from the installer. In this particular round, one of the issues that surfaced after release was that the installer uses a script function to modify PATH that just happens to misbehave if the PATH is long enough. If the uninstaller works as it should, users affected by this should be able to restore their system by running the uninstaller, then be able to use the installer in "unpack only" mode, without having to fetch another 50 megabyte copy of the same files.

As nearly every Haskell installer before, this one has given further reason not to trust Haskell installers (mostly just too many variations of windows configurations, too many things that can go wrong, for any volunteer effort to avoid all traps in the first attempt; plus some inertia against following suggestions from experience in the face of self-imposed deadlines), so please do not remove the failsafes!-)

[refold]

What I think we should do is provide an "express mode" that doesn't confuse the users with so many choices. So basically, the installer will have three modes: express (the default), which doesn't ask any questions and just performs the standard install; "just unpack"; and "customize", which lets you pick options. I can also probably fix the uninstaller so that it doesn't require storing $INSTDIR in registry (part of #19); in that case the uninstaller will be created even in the "just unpack" mode.

I agree that installer actions should be better documented (#36).

If the uninstaller works as it should, users affected by this should be able to restore their system by running the uninstaller

So you want the installer to save the previous state of the PATH variable? What if it gets altered during the time the Haskell Platform was still installed? Then PATH will be overwritten with the old value by the uninstaller.

[claus]

If the uninstaller works as it should, users affected by this should be able to restore their system by running the uninstaller

So you want the installer to save the previous state of the PATH variable? What if it gets altered during the time the Haskell Platform was still installed? Then PATH will be overwritten with the old value by the uninstaller.

To clarify: saving the state (rather than state modifications) is not something each installer script should have to do explicitly. I was merely hoping that the environment variable modification script authors, being aware of their issue, would have taken this precaution to spare their users some grief..

If that isn't the case, the last hope for people affected is System Restore. Creation of Restore points is usually triggered by installers, though this seems to require a plugin for NSIS (no idea whether that does what it says). If that didn't happen for the installer in question, the very last hope are the automated Restore points (see MSDN reference above).

[refold]

I, for one, always turn off System Restore, because the only time I tried to use it it botched up my system (Windows Me) completely.

The PATH issue was fixed through other means (see discussion in #25).

[refold]

Milestone 2009.4.0 deleted

[MtnViewMark]

Milestone 2010.4.0.0 deleted

[refold]

This section is now marked as RO.