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

[Duncan Coutts]

On Sun, 2007-10-21 at 23:42 +0200, Udo Stenzel wrote:
> Duncan Coutts wrote:
> > 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.
> 
> Exactly what I did, and I consider that a crock, not a solution.

I agree, that's what I said.

> > 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).
> 
> IOW, on GHC 6.6 I'm stuck with bytestring-0.8 and no package that
> expects bytestring >= 0.9 will work unless it contains an ugly
> workaround (an #ifdef).  Unless my memory is failing me, that was not a
> design objective of cabal. 

Indeed. That was not a design objective. However it's not something
Cabal can change, it's a property of the underlying Haskell
implementations. Currently it is not possible for a program to use two
packages that have overlapping exposed modules. Also, it is essentially
impossible at the moment to upgrade the base library on an existing ghc
installation. These two facts together are why ghc-6.6 users are stuck
with the implementations provided by base-2.x and cannot overlay things
on top. It is also the motivation for breaking up the base package into
smaller pieces which can be upgraded independently. (The base package
itself will still not be easily upgradable but the other packages that
were split out do become upgradable).

> > 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.
> 
> I'm suggesting to pretend that base never included ByteString, to have
> an empty bytestring-0.8 package for GHC-6.6 (that just copies the
> configuration of base) and to have bytestring > 0.8 fix the
> configuration of base for GHC-6.6.  GHC-6.6 is broken, and I'm
> suggesting to fix it instead of accepting the breakage.

I see why it's an attractive solution but I just don't think it is
practical. We cannot go changing existing installations just like that.
For one thing it's only possible for root users. For another one is not
supposed to modify packages managed by the system package manger. We'd
never get everyone to change.

> If this was the right time for grand visions, I'd propose a feature
> comparable to Provides: and Replaces: of Debian's apt, maybe combined
> with packages that re-export modules and a better mechanism (read: any
> mechanism) to resolve conflicts between packages.  base may not be
> upgradeable, but parts of it are.  Oh, and I think multiple packages
> providing the same modules and then causing conflicts is just a bad
> idea, unless of of them took precedence.

I agree, any of these things would be great. At the moment none of them
are implemented (and they cannot be implemented in Cabal without
corresponding support from the Haskell implementations).

> > 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.
> 
> So the API of ByteString 0.8 is now fixed and nothing is allowed to
> depend on anything newer, and that will be the case for at least the
> next 2 years (until GHC 6.8 trickles down into Linux distributions in
> actual use).  Correct?

Right. In practise that's not too bad since the public api of bytestring
hardly changed. The internal changes only affect extension packages that
use the internal api, things like binary.

> Unless I need recent developments.  Then I just copy the Data/ByteString
> tree into my project directory...

Funnily enough that's the only thing that will work, because ghc allows
local modules to mask ones from a package like base, but not for modules
from two used packages to overlap. There's not a lot Cabal can do to
work around that.

> > 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.
> 
> And does that feel right to you?  Should they actually need tweaks?

No. I'd have preferred a better solution. Cabal configurations were not
designed with this purpose in mind. You listed several better solutions.
However the base breakup went ahead without any of them in place. The
only currently implemented solution is to take advantage of
configurations. As you notice the configurations syntax for this purpose
is a bit clumsy, because it was designed for a slightly different use
case. If we do not want to use configurations in the upcoming ghc
release then the alternative is for the accompanying packages to *only*
work with base 3.0. I think it's better for them to work with older
releases too, which is why I've been modifying many of them to use
configurations. If I stop or revert those changes you'll just get
packages that cannot be used with ghc-6.4/6.6 at all without hacking
build files.

> Whatever... right now it feels like messing up my 'base' configuration
> was exactly right, I can stick with cabal-1.1.6.2 if I want, and having
> to edit .cabal files is just part of the game.  So be it.  I can't
> convice you of my idea of the correct fix, and I don't need to.

I'm not the one you need to convince. I'd be very happy with a better
solution. However nobody is seriously talking about delaying imminent
releases to implement a better solution. That is what you would need to
change.

> [Don't get me wrong: your (that's Duncan, Don, Bjorn, and many others I
> forgot) software is great.  Haskell without ByteString is just not up to
> processing large files, and the reason this situation pisses me off is
> that I _want_ to use the latest developments and Cabal _should_ make
> that easy, but it doesn't.]

Cabal is not the only thing involved in how the package system works. I
suggest your irritation is misdirected at the most obvious user-visible
part of the system.

Duncan