Fwd: hackage compile failure with QuickCheck 2.5

Dear Levent,
I think this [1] could be related.
Regards,
Alexander Foremny
PS. Sent this to Levent directly. Here's a copy for the mailing list.
Sorry for the noise.
[1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html
---------- Forwarded message ----------
From: Alexander Foremny
[This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.]
I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is:
[13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o )
Test/QuickCheck/All.hs:15:1: Bad interface file: /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH
The full log file is at (search for "Something is a miss" in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4
Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package.
Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency.
I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.)
-Levent.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Thanks Alexander. However, I'm not sure how to use the workaround described so I can get hackage to properly compile my package. It sounds like I have to add a "template-haskell >= 2.7.0.0" dependency to my own cabal file, which sounds like the wrong thing to do in the long-run. Is there something that can be done on the hackage/ghc side to avoid this issue? Or something less drastic than adding a template-haskell dependency on my own package's cabal file? Thanks, -Levent. On Tue, Jul 17, 2012 at 7:31 AM, Alexander Foremny < alexanderforemny@gmail.com> wrote:
Dear Levent,
I think this [1] could be related.
Regards, Alexander Foremny
PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise.
[1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html
---------- Forwarded message ---------- From: Alexander Foremny
Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok Dear Levent,
I think this [1] could be related.
Regards, Alexander Foremny
[1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html
2012/7/17 Levent Erkok
: [This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.]
I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is:
[13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o )
Test/QuickCheck/All.hs:15:1: Bad interface file:
/usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi
Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in
the
interface file template-haskell:Language.Haskell.TH
The full log file is at (search for "Something is a miss" in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4
Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package.
Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency.
I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.)
-Levent.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Which package are you trying to build? Is it a local package that
fails to build or something on Hackage? Its .cabal file or at least
full dependencies would be of interest.
Regards,
Alexander Foremny
2012/7/17 Levent Erkok
Thanks Alexander. However, I'm not sure how to use the workaround described so I can get hackage to properly compile my package. It sounds like I have to add a "template-haskell >= 2.7.0.0" dependency to my own cabal file, which sounds like the wrong thing to do in the long-run.
Is there something that can be done on the hackage/ghc side to avoid this issue? Or something less drastic than adding a template-haskell dependency on my own package's cabal file?
Thanks,
-Levent.
On Tue, Jul 17, 2012 at 7:31 AM, Alexander Foremny
wrote: Dear Levent,
I think this [1] could be related.
Regards, Alexander Foremny
PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise.
[1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html
---------- Forwarded message ---------- From: Alexander Foremny
Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok Dear Levent,
I think this [1] could be related.
Regards, Alexander Foremny
[1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html
2012/7/17 Levent Erkok
: [This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.]
I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is:
[13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o )
Test/QuickCheck/All.hs:15:1: Bad interface file:
/usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH
The full log file is at (search for "Something is a miss" in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4
Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package.
Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency.
I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.)
-Levent.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

With ghc 7.4.1, cabal-install 0.13.3 and Cabal 1.14.0, % cabal install --avoid-reinstalls sbv-2.2 fails to find a plan without reinstalls, and recommends --solver=modular. % cabal install --solver=modular --avoid-reinstalls sbv-2.2 reinstalls template-haskell-2.6.0.0, which breaks the GHC installation. I've added the suggested --constraint='template-haskell==2.7.0.0' option as a workaround, but it seems the --avoid-reinstalls option is being ignored.

Ah, that explains why the hackage page mysteriously got fixed. Thanks for
looking into this Ross.
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.
-Levent.
On Tue, Jul 17, 2012 at 10:26 AM, Ross Paterson
With ghc 7.4.1, cabal-install 0.13.3 and Cabal 1.14.0,
% cabal install --avoid-reinstalls sbv-2.2
fails to find a plan without reinstalls, and recommends --solver=modular.
% cabal install --solver=modular --avoid-reinstalls sbv-2.2
reinstalls template-haskell-2.6.0.0, which breaks the GHC installation.
I've added the suggested --constraint='template-haskell==2.7.0.0' option as a workaround, but it seems the --avoid-reinstalls option is being ignored.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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.
participants (4)
-
Albert Y. C. Lai
-
Alexander Foremny
-
Levent Erkok
-
Ross Paterson