(moving to haskell-cafe) On Sun, 2007-10-21 at 14:55 +0200, Udo Stenzel wrote: > 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.
Right. > 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?). Right. It expects that if you have base >= 2.0 && < 2.2 then that version of base exports Data.ByteString. That's not an unreasonable assumption I think. You can hack the .cabal file further to make it work in your situation, but I don't suggest that's a great long term solution. If you wanted to hack it you'd change it to just: build-depends: base, bytestring >= 0.9 without any 'if' or flags and without cpp-options: -DBYTESTRING_IN_BASE. > 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? So you've changed the API of base-2.1.1 so that will break packages that expect that they know what the api of base-2.1.1 actually is. You can either hack the .cabal files of things you try to install (which would be a pain, I don't recommend it) or you could revert your changes to your base package. > For the time being, I'll go with 'ghc --make'. And I think that cabal > configurations are an exceptionally bad idea carried to perfection. Don't get me wrong, I'm not claiming that the changes in what is in and what is out of the base package could not have been handled better. Configurations just happen to be one mechanism that we have available now to enable packages to build with various versions of the base package. The other alternative seemed to be that they'd only work with an old or a new version but not both. There are plenty of things that we could have done better to make the base changes less disruptive but I really don't think you can blame configurations for that or for adding to that problem. If we had made different decisions at various points we would not need configurations for this purpose right now. We'd still need configurations for other things. Configurations serve other purposes too. They're not just for managing the mess over moving modules between packages. They're generally to allow changes in the way a package is built depending on the environment in which the package is built to reduce the need for non-portable configure scripts and wadges of fragile code in Setup.hs files. > 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.) It's mostly orthogonal to the Haskell implementation since the base package is shared by all Haskell implementations. > 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? What kind of change are you suggesting? We have to support base 2.x because that is the versions of base that come with ghc-6.6.x. We cannot sensibly install the separate bytestring package with ghc-6.6.x because it would clash with the base package there. We cannot easily upgrade base in existing installations of ghc because ghc is just not designed with that in mind at the moment. The solution we're using at the moment is to use the separate bytestring package with ghc-6.4 and ghc-6.8 and to use the version of the bytestring code in base-2.x for ghc-6.6.x. That's what the newest versions of zlib, bzlib, iconv, binary, tar etc do. They all work with ghc-6.4, 6.6 and 6.8 (using Cabal-1.2.x). > > 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... So far this weekend I've uploaded to hackage: Cabal-1.2.1, bytestring-0.9, unix-compat-0.1.1, tar-0.1.1 and Kolmodin uploaded binary-0.4.1. When hackage itself is using Cabal-1.2.1 then I can also upload zlib-0.4, bzlib-0.4, iconv-0.4. All these packages (with the exception of bytestring-0.9 with ghc-6.6 as I explained) work with all recent versions of ghc. I've also been checking that the packages that will come with ghc-6.8 will also work with ghc-6.6 and 6.4 (where it makes sense for them to do so). These packages will be released separately on hackage too. This required using configurations in many cases to allow the packages to build with several base/ghc versions. I do understand you've have a bad experience with incompatible bits of software and different versions of build systems etc, but I really think the situation is not that bad. The right thing to do is to use the latest Cabal-1.2.x with whichever version of ghc you happen to have and not to use a hacked version of base. There is no need to upgrade immediately to ghc-6.8, in fact at the moment that'd make the situation worse since most packages need tweaks to work with it. Duncan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe