RE: cabal release (was: cabal experiences)
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'. Cabal is something of a special case, because its use is pretty much restricted to Setup.lhs scripts, which can be considered part of the build system rather than the code of a library or application. So this is build system API breakage, not library API breakage, m'lud ;-) 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. Cheers, Simon
"Simon Marlow"
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. peace, isaac
participants (2)
-
Isaac Jones -
Simon Marlow