mysterious cabal-install problems

问题

With a clean install of the "Haskell Platform". (OS X Snow-Leopard & Platform 2010.1.0.1), doing this causes simple sequence causes very weird cabal install behaviour:

$ cabal install time

$ cabal install random

$ ghc-pkg list random
/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.1/package.conf.d
   random-1.0.0.2
/Users/yairc/.ghc/i386-darwin-6.12.1/package.conf.d
   random-1.0.0.2

random-1.0.0.2 is installed twice in my system. and now doing cabal install random reinstalls random-1.0.0.2 every time.

Looks like random depends on time, and cabal wants to reinstall it after there's a new version of time available? And because of two random-1.0.0.2 cabal is confused and always thinks it's not up to date because it's looking at the first one?

ghc-pkg check finds no errors.

回答1:

Please do

ghc-pkg check

and if that shows no errors, let's see the output from

ghc-pkg list -v

and

cabal install random -v

Edit: I can reproduce your problem with GHC 6.12.1, but not with 6.12.2, using exactly the same version of cabal-install (0.8.0). I'll look into it.

Edit 2: reported as a bug in cabal-install.

回答2:

I have two possible solutions, both of which are somewhat dangerous but should get you a working installation. I'm glad Simon's following this because it sounds like some sort of bug to me. To get a working installation, I would try the following first:

ghc-pkg unregister random

then do ghc-pkg list random to see what's installed. I would guess (but I'm not sure) that you'll still have the /Library/Frameworks version (from the Platform) but the newly-installed version will be gone. If this is the case, proceed to the next step. If it isn't you'll probably need to do a clean reinstall of the platform.

Assuming the platform random is still present, do this:

cabal unpack random

cd to the directory it's unpacked into, and edit the .cabal file by bumping the version to 1.0.0.2.1 (add another field and increment it by one). Then cabal install from that directory and it should install the new random. Since this has a different version than the platform random, the two can safely co-exist.

Rather than doing the ghc-pkg unregister, you can directly delete the registration file from

/Users/yairc/.ghc/i386-darwin-6.12.1/package.conf.d

the file name will have a hash appended to it, so you'll need to look at the directory contents to actually get the value. Just delete the file and ghc-pkg and cabal shouldn't see it from then on. This won't touch the platform installation (so it's safer in that sense), but the potential is still there to hose other installed packages. After this, you can re-install the random package by unpacking and incrementing the version as above.

回答3:

I'll describe the work-around that worked so far for me. I've tried many different things but I'll only described here the attempt that worked.

(btw: I'm using Mac OS X 10.6.4 and your results might be different on different systems)

I installed GHC 6.12.3 from source. Don't remove your previous GHC as building GHC requires it.
I removed the symlinks at /usr/bin (for ghc, ghci, ghc-pkg, and runhaskell) to my previous GHC which was the one from the Haskell Platform 2010.1.0.1 installer.
I installed cabal-install using it's bootstrap.sh script.
I installed patched versions of the random and haskell98 packages. The differences are just in their .cabal files
- bumped random's version up to 1.0.0.2.1 and changed it dependency on time to be time == 1.1.*
- bumped haskell98's versions up to 1.0.1.1.1 and that's it
I ran cabal update and cabal upgrade to see which packages are out of date. I did cabal install those. I believe that this helps reach a stable-state faster. (note that syb's install failed and that cabal install parsec said there's nothing to do about it when cabal upgrade said differently. So I left those two packages alone)

I validated that my setup is ok by running ghc-pkg check between stages. Sometimes it breaks because a package gets reinstalled over a previous version with same version number and packages that depended on it need to be reinstalled. When that happens I cabal install the broken packages again.

I also used the following program to verify that my setup doesn't contain two packages with the same version:

import Data.List (sort)
import Data.Maybe (fromJust)
import System.IO (hGetContents)
import System.Process (CreateProcess (std_out), StdStream (CreatePipe), createProcess, shell)

main :: IO ()
main = do
    pkgListRaw <-
        createProcess (shell "ghc-pkg list") { std_out = CreatePipe }
        >>= hGetContents . fromJust . sndOfFourTup
    let pkgListSorted = sort . filter (not . null) $ lines pkgListRaw
    putStrLn .
        unlines . map (dropWhile (== ' ') . fst) .
        filter (uncurry (==)) . zip pkgListSorted $ tail pkgListSorted
    where
        sndOfFourTup (_, x, _, _) = x

I cabal installed hlint, yesod, haddock, HDBC-mysql, hakyll and other packages and then I cabal installed the previous list again and again until my setup reached a "stable state" in which cabal install doesn't reinstall any of those.
I verified that my own programs I'm working on now compile and work. All seems to be fine now

Notes:

I couldn't get Haskell Platform 2010.1.0.1 to work. Things only worked for me after I upgraded to GHC 6.12.3. Ironically (?), this goes against the recommendation on GHC's download page:

Stop!

For most users, we recommend installing the Haskell Platform instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together.

This work-around will probably break sometime in the future as well. I guess that this will probably happen in a few months. A core library like random will get updated and then dependency problems will start to unravel again. Then I'll/you'll have to spend time on getting our setups fixed. Perhaps then it would require upgrading to a newer GHC. But who knows, maybe then it will be an older release that will become stable as hackage packages get updated to solve dependency related problems. As a service to you, I will update this question and answer when the time comes. (Assuming that others are having this problem too. So far I validated that Simon Marlow and Peaker face this problem too)
Ways to know that your Haskell setup is broken (if any of these is true then the setup is broken):
- Nothing works
- ghc-pkg check says that it is broken
- The short program whose source I put in this answer above finds that you have a package installed twice with the exact same version
- cabal update and then cycle cabal installing the list of packages I wrote above, or another list (preferably a big one with lots of dependencies). If you never reach a stable-state (an iteration of the cycle always reinstalls something) then your setup is broken. WARNING: This step may destroy your currently functioning Haskell setup. Do this if you are maso-curious or willing to fix your setup after it breaks (a process which might be time consuming)
I would like to know whether your setups are broken or working. This could help me. For example if we find that GHC 6.10 setups are working fine, I/U could recommend those setups to people on the occasion of recommending to someone to try out Haskell etc.

I hope that this helps others facing the same or similar problems. Many thanks to Simon Marlow and John!

来源：https://stackoverflow.com/questions/3119782/mysterious-cabal-install-problems

标签

haskell

cabal

hackage

cabal-install