Use update-alternatives for handling generic tool names
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.
Showing with 27 additions and 21 deletions