FS#31864 - [cabal-install] 0.16.0 Fails immediately with own default configuration
Attached to Project:
Arch Linux
Opened by Bardur Arantsson (ba_) - Tuesday, 09 October 2012, 17:03 GMT
Last edited by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 21:45 GMT
Opened by Bardur Arantsson (ba_) - Tuesday, 09 October 2012, 17:03 GMT
Last edited by Thomas Dziedzic (tomd123) - Saturday, 13 October 2012, 21:45 GMT
|
Details
Description:
Cabal-install 1.16.0 + Cabal 1.16.0 fails to work with its own default configuration. Additional info: cabal-install version 1.16.0 using version 1.16.0 of the Cabal library Steps to reproduce: $ rm -rf ~/.cabal # To force a new default config being written $ cabal update # To write default config Config file path source is default config file. Config file /home/bardur/.cabal/config not found. Writing default configuration to /home/bardur/.cabal/config Downloading the latest package list from hackage.haskell.org $ cabal install foo cabal: Command.optionToFieldDescr: feature not implemented Removing the "jobs" option from the config installed in ~/.cabal/config gets cabal-install up and running. Do note the following two threads which seem to indicate that what's labeled as Cabal 0.16.0 is severely broken and there's a new Cabal + cabal-install combo out which should hopefully address this issue: http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/9211 http://permalink.gmane.org/gmane.comp.lang.haskell.cabal.devel/9233 |
This task depends upon
Closed by Thomas Dziedzic (tomd123)
Saturday, 13 October 2012, 21:45 GMT
Reason for closing: Fixed
Additional comments about closing: pkgrel 2 adds a patch to remove the buggy line
Saturday, 13 October 2012, 21:45 GMT
Reason for closing: Fixed
Additional comments about closing: pkgrel 2 adds a patch to remove the buggy line
Why are you assuming it wasn't tested?
It was in [testing] for a week and everyone who used it probably never rm -rf ~/.cabal
Anyways, I will look into upgrading cabal-install
Thanks a bunch.
There is nothing that forces you to remove it, you only have to remove the libs, which are located in the .cabal/libs folder
also note that libs under the libs folder have a compiler version under each of them
I'm not sure what the best path is here:
Patch cabal that is in ghc and cause a mass rebuild of existing packages, or let this bug stay until the next ghc release.
http://hackage.haskell.org/trac/ghc/ticket/7324
I'll wait and see what they have to say.
My reading of the first post I linked to is that the Cabal library shipped with 7.6.1 is some "random" snapshot of the in-development Cabal 1.16.0 (which is recognized by everyone as happening to be broken), so patching the bundled Cabal up to 1.16.0.1 would probably be the most "correct" course of action.
Would this really lead to a huge number of rebuilds, though? Wouldn't it only be packages which actually *depend* on the Cabal library would require rebuilds? (Or does the Cabal hash "infect" the "base" package hash or something like that?)
It would be a real shame to have to wait until 7.6.2 to get a fix for this. There may be bugs that may be lurking in the bundled Cabal, but I'm not exactly sure *how* broken this Cabal snapshot is -- I immediately installed a new Cabal + cabal-install, using the broken one to bootstrap.
Since Cabal ships with ghc, we would have to rebuild ghc with an updated Cabal library.
But rebuilding ghc requires rebuilding all haskell packages because haskell doesn't have a stable abi.
I will wait to see what upstream says before deciding on anything.
https://github.com/haskell/cabal/commit/aa7d98f72f4a06ab2ab12defd046a21872a718d8
looks like the next cabal-install will have a workaround for this issue
Now to find when the next cabal-install release will happen