Duncan Coutts wrote:
New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar and others (zlib, bzlib, iconv) will appear on hackage in the next few days.
I just tried one of them, iconv. First it wants a recent cabal; that's fine, I installed the darcs version. Then I get this: | Codec/Text/IConv.hs:64:17: | Could not find module `Data.ByteString': | it is a member of package bytestring-0.9, which is hidden Okay, it obviously tries to be smart, but doesn't know that I upgraded to a separate ByteString library. So I take out the gunk about 'flag(bytestring-in-base)' and try again: | Setup: At least the following dependencies are missing: | base <2.0||>=2.2 Of course that was to be expected, since I have base-2.0 hacked to not get in conflict with bytestring-0.9, and you (Duncan) couldn't possibly anticipate this (or could you?). Now what am I supposed to do? Give my messed up base a new version number? (Which one?) Rewrite every single cabal file, hoping that they never become Turing complete turning the exercise into a reverse engineering fest rivaling the ICFP contest? Bite the bullet and install GHC from darcs? For the time being, I'll go with 'ghc --make'. And I think that cabal configurations are an exceptionally bad idea carried to perfection. They make things worse, not better. (And that's just GHC 6.6... I don't want to even think about what happens on Hugs, JHC and YHC.) What would it take to talk you into giving up on supporting the broken base-2.0 and incorporating a patch to unbreak it into the bytestring setup? Can I stop the insanity by simply writing that patch?
So all will not be plain sailing for the first few weeks after ghc-6.8 comes out as maintainers update their packages. People will have to be patient and/or stick to ghc-6.6 for a bit.
Okay, so now we have *three* almost-stable versions of GHC in wide circulation, all of them broken in different ways with respect to cabal packages. I feel tears welling up... -Udo