[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