upgrading GHC

Simon Marlow simonmarhaskell at gmail.com
Thu Feb 21 09:43:00 EST 2008

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.


More information about the Libraries mailing list