
duncan.coutts:
On Thu, 2008-09-04 at 12:09 -0400, David Menendez wrote:
On Thu, Sep 4, 2008 at 5:19 AM, Duncan Coutts
wrote: That's exactly the same situation as with Gentoo. We provide a ghc-updater program that re-installs all the existing libs for the new ghc. Gentoo also only provides libs for ghc.
That's more convenient than re-installing all the libs by hand. I guess that's good enough for non-developer use; someone who just wants to install a program doesn't need to have more than one version of GHC installed, for example. It pains me to see the assumption that Haskell = GHC built in to our distribution methods, though.
Yeah, I know. It's really a limitation of systems like Gentoo. Gentoo's position is that you should not encode things like this into the package name and provides a 'slotting' mechanism to allow multiple versions, however it's not quite expressive enough to slot on the haskell implementation and still get all the lib deps right.
RPM apparently handles this by having the library packages install themselves under new names that include the environment name and version. I assume Nix can handle multiple Haskell environments.
Right. And yes, Nix can do everything because it's jolly cunning and takes the functional/persistent approach.
Does anyone know whether arch linux and debian can handle multiple Haskell environments?
Debian does, again by encoding the haskell implementation name into the package name. I think arch only provides libraries for ghc.
That's right, on Arch we just go for what people actually need, i.e.: 1) 1 compiler, GHC 2) GHC comes with the core+extra set, so they're implicitly available 3) all other libs are "haskell-(map toLower packagename)" The complication to support multiple implementations et al isn't done by any other language group (i.e. libs aren't bundled for multiple python impls, or different C compilers), so I don't see why we should waste time on that either. Pragmatic, I know. -- Don