cabal release

Sven Panne Sven.Panne at
Tue Dec 27 05:10:40 EST 2005

Am Donnerstag, 15. Dezember 2005 09:21 schrieb Ketil Malde:
> [...]
> Anyway, I expect most users to install via OS packages (rpm,deb,..),
> and distributions tend to have their own solutions for this kind of
> thing (/etc/alternatives springs to mind).

Yes, this is definitely the way to go. We should not try to duplicate existing 
functionality, probably in a much inferior way. All major Linux distributions 
(SuSE, Fedora, Debian, ...) use update-alternatives or a home-grown variation 
of this. Our OS packages should use this to existing mechanism and leave 
decisions like replacing or not to the underlying package manager and 
configuration files.

I have to admit that I have been too lazy to fix the RPM .spec files in the 
repository to use update-alternative... :-] Let's see if I can find some 

> 'runhaskell' could perhaps also be a small script that checks for the
> availability of 'runhugs', 'runghc', etc.  This way, it could be the
> same for all Haskell implementations, and the choice could be
> configurable on a user basis (rather than per system).  It would cost
> a bit of startup time, though.

That's again duplication: runhaskell is simply a link to the "real" executable 
and is under control of a cleanly separated mechanism like 
update-alternatives, no script hackery needed. The mechanism to make this 
configurable per-user is ~/bin/ and/or PATH, so there is no need to 
complicate things.

I've been talking about Linux and *nix only above, but I'm sure other 
platforms have similar mechanisms.


More information about the Libraries mailing list