Duncan Coutts wrote:
On Thu, 2008-02-21 at 08:12 +0100, Henning Thielemann wrote:
It was said, that Cabal would work also with GHC-6.2. I didn't get it running and then switched to GHC-6.4. It was said, that multiple versions of GHC can be installed on the same machine. That's somehow true, but e.g. runhaskell cannot be told which actual GHC binary to use, and thus it is not possible to run Cabal with a compiler or a compiler version different from the compiler to be used for the package.
It's always possible to: ghc-6.4.1 --make Setup.hs -o setup ./setup configure ...etc
rather than using whatever ghc runghc/runhaskell finds on the $PATH. I keep 3 versions of ghc installed this way to test Cabal and other stuff.
I decided to upgrade to Cabal-1.2, which also needed installation of filepath. I know that installation could be simplified with cabal-install, which has even more dependencies, and thus I canceled this installation project. Then I have equipped my Cabal files with a switch on splitBase, which merely duplicates the globally known information that former base-1.0 package is now split into base-2.0 or base-3.0 and satellites. It doesn't give the user any new value, but costs a lot of time for the package maintainer. I wonder if it would have been simpler to ship GHC-6.8 with a base-1.0 package or provide it on Hackage that just re-exports the old modules in the known way.
We know this issue is a mess. We've discussed it at length. http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility
Sadly at the moment it is impossible to supply a base-1.0 with ghc-6.8 because packages cannot re-export modules and even if they could, ghc and cabal would have no way to figure out if a particular program was intended to use one or the other.
Duncan's right, and we do plan to tackle this problem in 6.10. But there's something practical that the community could do *right now* to make everyone's life easier. We've talked about this before at various times, but I thought I'd mention it again in case it inspires anyone to stand up and volunteer to spearhead the effort. The idea is to have a group of people who manage "distributions" of Haskell software. The idea would be similar to how GNOME works, where they have a collection of software components bundled together, tested and released as a coherent unit. Each individual component is maintained separately and has its own release cycle, but the distribution managers bundle up a set of mutually-compatible components and call it "GNOME version x.xx", releasing new distributions on a time-based cycle. So the advantage of doing this would be that someone can easily get a version of a package that is compatible with the other packages they already have. Cabal/Hackage would know which distribution your installation is based on, and it would automatically grab the right version of the package you need. When upgrading a distribution you do it all-at-once. No problems with upgrading packages piecemeal and getting into a mess with multiple versions of dependencies. I think doing this would deliver a system that "just works" for the majority of users most of the time. But it needs people to drive it and make it happen. Cheers, Simon