[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Duncan Coutts]

(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