upgrading GHC

[Duncan Coutts]

On Thu, 2008-02-21 at 16:19 +0100, Henning Thielemann wrote:

> > 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.
> 
> I can't follow here. I think it must be possible to provide a base-1.1
> which exports the same modules as base-1.0 but gets them from other
> packages. It can be considered the last version of the base-1 series and
> the transition to base-2.0.

Ok it would be possible to have two distinct base packages (though there
is a restriction in ghc that would need to be lifted first). It would
not be a very helpful situation however since base-1.0:Prelude.Int /=
base-2.0:Prelude.Int so you'd have to have completely separate stacks of
packages for each version of base.

Our package infrastructure is just not up to dealing with that at the
moment. We have enough problems when we upgrade bytestring and then have
packages depending on packages that were built against different
versions of that package. For example see:
http://hpaste.org/5803

> Btw. I had problems with hidden packages in GHC-6.4.1. They still interfer
> with other package versions, and thus I have to unregister all versions of
> a package but one, in order to get something compiled. Is this a known
> issue of GHC-6.4.1 or am I expecting the wrong behaviour of ghc-pkg?

It's a known issue in GHC-6.4.1, it's fixed in 6.4.2. I would recommend
you upgrade but you've already told us the long list of reasons why that
is impractical.

> I thought the exposed version is visible in GHCi and without -package
> option, whereas the hidden but registered packages can be imported with
> -package and thus Cabal.

Yes, in 6.4.2 and later.

Duncan