ATTENTION: Packagers should read the following stuff carefully!

GHC, Hugs and nhc come with various tools like runhaskell or hsc2hs. On the
one hand this is quite handy, avoiding lots of tiny native packages, but OTOH
this leads to a few problems:

   * The tools are not always identical in functionality.

   * The tools fight for a global generic name like "/usr/bin/runhaskell".

These problems are not new and not unique to Haskell implementations, so for
*nix-based system there is a tool called update-alternatives which handles
those cases. The idea is as follows:

   * Each program/man page/etc. installs itself with a very specific name
     like /usr/bin/hsc2hs-ghc or /usr/share/man/man1/lua5.1.1.gz, so nothing
     clashes.

   * The (un-)installation scripts call update-alternatives to notify the
     system about new alternatives for a generic tool/manpage/etc.

   * Alternatives can be grouped together ("link groups"), so e.g. switching
     from Sun's Java to Kaffe switches compiler, JRE, manpages etc. together.
     Alas, this doesn't work well with the Haskell implementations yet,
     because they come with different sets of tools (in addition to runFOO):

       GHC:  hsc2hs
       Hugs: hsc2hs, cpphs
       nhc:  cpphs

     Either these tools should be disentangled fromt the Haskell
     implementations or all implementations should offer the same set.
     Opinions and recommendations on this topic are highly welcome.

   * This mechanism can be used to easily switch between several versions of
     the same implementation, too, but we are not yet fully prepared for that.

As a first step, GHC now installs hsc2hs as 'hsc2hs-ghc' and does *not*
install runhaskell directly anymore, only runghc. hsc2hs and runhaskell are
created via update-alternatives now. What is currently missing is a mechanism
for platforms like Windows and probably Mac OS X.