Daily report for head

[Claus Reinke]

>> 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