In this case, I was told that base3-compat was provided
explicitly to avoid breakage[1], and as I reported, that
doesn't seem to be the case [2].
It'll only work for packages that correctly depend on something like:
base >= x && < 4
quoting self (again):
|Then, after adding "base < 4" to all extralibs .cabal files, I'm
|treated to a
|
|Network.hs:434:10:
| Couldn't match expected type `Exception.IOException'
| against inferred type `Exception.Exception'
| Expected type: Exception.IOException -> IO a
| Inferred type: Exception.Exception -> IO a
| In the expression: Exception.catch
| In the definition of `catchIO': catchIO = Exception.catch
and, in case that was ambiguous in any way:
$ darcs whatsnew --repodir=libraries/network/
hunk ./network.cabal 22
-build-depends: base, parsec
+build-depends: base < 4, parsec
$ grep base libraries/network/network.cabal
build-depends: base < 4, parsec
Packages that just depend on "base" won't work. Nor will packages that
have been updated to work with:
either base >= x && < 4
or base >= 4 && < 5
but haven't kept their base 4 sections up-to-date.
As I've mentioned, I see those extralibs as a good test of
whether changes to ghc+corelibs are going to cause havoc
in the wild,
As extralibs are likely to be partially updated, I don't think they are
necessarily a good test of what is likely to happen in the wild.
If ghc changes break extralibs, chances are that other packages
will experience worse. If the extralibs follow ghc changes, that
doesn't mean that other package are safe, but it does mean that
some non-core packages have been able to adapt to the ghc
changes - in this case, that the suggested backwards compatibility
solution has been tested successfully in some popular packages.
Claus
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
