
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