[Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5

Albert Y. C. Lai trebla at vex.net
Fri Jul 20 21:44:10 CEST 2012


On 12-07-17 01:43 PM, Levent Erkok wrote:
> It still feels like this'll start biting more folks down the road. I've
> created the following cabal ticket so it can be tracked:
>
> https://github.com/haskell/cabal/issues/978
>
> However, my understanding of the problem is rather incomplete; please
> feel free to add comments to the ticket.

I apologize for not being interested in a github account (at least for 
now), and therefore not posting there.

1. I am not convinced that it is a cabal issue.

sbv-2.2 demands containers >= 0.5 --- which most GHC versions don't have 
--- and template-haskell depends on containers. This requires replacing 
template-haskell or adding a new instance of template-haskell. As long 
as you or an algorithm obey dependencies, there is no way around it.

In fact, cabal-install since 0.14 already adds a hesitation. It aborts 
and warns "likely to be broken by the reinstalls". If you use 
--force-reinstalls, it is your poison.

Why is it a cabal bug to obey human-decreed dependencies and instructions?

2. It is a very bad idea to keep around multiple versions of containers, 
multiple versions of template-haskell... generally multiple versions and 
instances of what comes with GHC. The GHC API (package name "ghc") 
depends on them, too. Are we going to rebuild GHC multiple times too?

See my http://www.vex.net/~trebla/haskell/sicp.xhtml#pigeon
In fact, see the whole article.

A rumour says that my article caused adding the hesitation to 
cabal-install 0.14. My article was written before.

3. I see that now we have sbv-2.3, and its dependency reads: containers 
== 0.4.2.1

So now people using GHC 7.0.x, 6.12.x... have to add multiple versions 
of containers, rebuild template-haskell, and go through the same ordeal 
again.



More information about the Haskell-Cafe mailing list