upgrading GHC

[Simon Marlow]

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