cabal release

Isaac Jones ijones at
Tue Dec 13 20:27:56 EST 2005

"Simon Marlow" <simonmar at> writes:

> On 12 December 2005 15:31, Ian Lynagh wrote:
>> On Mon, Dec 12, 2005 at 03:14:09PM +0000, Duncan Coutts wrote:
>>> In Gentoo we made a decision to ship Cabal-1.1.3 with GHC 6.4.1.
>>> That is after installing GHC 6.4.1 we unregister Cabal-1.0 and
>>> install Cabal-1.1.3.
>> If all distributions and users are going to have to do this to get a
>> usable system[1] then it seems obvious to me that ghc should already
>> come this way. That it doesn't causes headaches for packagers IME.
> I tend to agree.  I'm not against breaking the rules in this case, since
> shipping Cabal-1.0 in 6.4.2 would be distinctly sub-optimal.  Shipping
> two versions of Cabal is possible, but the build system isn't really set
> up to do this, so it's non-trivial work, and it still requires the user
> to say 'ghc-pkg expose Cabal-1.1.4; ghc-pkg hide Cabal-1.0'.

Cool :)  What's the timeline for ghc 6.4.2?

> Cabal is something of a special case, 

Aw shucks ;)

> I'd be rather happier if we could solve the versioning issue with
> Cabal, so that upgrading Cabal in the future doesn't automatically
> break code.  It might not be possible to do this the first time
> around, but now is the time to design our way out of future
> problems.

We need to experiment with stuff.  People want to use the advanced
features like hooks on complex packages, but no one wants the
cabal-1.0 interface to hooks!  We're trying to maintain a tension
between experimenting and providing something stabler for simple
programs (just like Haskell itself).  It's bad if that breaks stuff,
but I don't want to end up in a situation where we tie ourselves to a
bad implementation because 3 packages used the old interface.  I think
we just need to be better about explicitly stating what is stable and
what is not.



More information about the Libraries mailing list