Not only shadowing. For example, when I installed warp-static, yesod, or gtk2hs. A clear-user-space may ease the problem and got them installed. But normally with a not brand new user space, it failed like above. And, the key point is that using upgrade-dependencies with cabal-install. I am using git (current) version of cabal-install. Without that argument, things could be fine. With it, it must fail. And ghc-pkg check reports no errors. On Tue, Nov 20, 2012 at 3:47 AM, Albert Y. C. Lai wrote:

On 12-11-19 04:45 AM, Ivan Lazar Miljenovic wrote:

...

On 19 November 2012 18:21, Magicloud Magiclouds > wrote:

...

<command line>: cannot satisfy -package Cabal-1.16.0: Cabal-1.16.0-**dd0ce1db6fea670a788547ee854114**86 is unusable due to missing or recursive dependencies: directory-1.2.0.0-**8edf300597b0da609c8eccc9aa6d0c**c3 process-1.1.0.2-**03ae5757aa509ffbe497f42660cba5**2c unix-2.6.0.0-**4bc27fc415f60036a88211de7cde3e**9a (use -v for more information)

What should I do? Why user space directory and process would interrupt Cabal in global space?

It shouldn't.

Can you please give an example of a package that gives you an error like this?

Also, what does "ghc-pkg check" say?

The only thing I can think of is that you're trying to upgrade a package like array, containers, etc.

It does. It has always been. When unioning user and global, user takes precedence: user directory-1.2.0.0 shadows global directory-1.2.0.0 (GHC User's Guide 4.9.4). But look closer: user directory-1.2.0.0-feedbabe... shadows global directory-1.2.0.0-deadbeef... Therefore, if global Cabal-1.16.0 was built against directory-1.2.0.0-deadbeef..., it's a missing dependency for you.

See my http://www.vex.net/~trebla/**haskell/sicp.xhtml#pigeonhttp://www.vex.net/~trebla/haskell/sicp.xhtml#pigeon

Fortunately, shadowing is a sessional property, not a data-loss property. One can say, it's a data-surplus property. To regain working sessions, cut surplus data, add -no-user-package-db to all your ghc and ghci commands.

"ghc-pkg check" does not report shadowing. Go straight for "ghc -v".

This is what you get for "--reinstall".

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

-- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

But I think it should be like this, right? Say ghc provids process-old, and Cabal-old depends on it. Then I use --upgrade-dependencies to install somePackage and so install process-new in user space. The process-old is still there. Why Cabal-old breaks and `ghc-pkg check` gets nothing? On Wed, Nov 21, 2012 at 8:47 AM, Albert Y. C. Lai wrote:

On 12-11-19 09:39 PM, Magicloud Magiclouds wrote:

...

And, the key point is that using upgrade-dependencies with cabal-install. I am using git (current) version of cabal-install. Without that argument, things could be fine. With it, it must fail.

Therefore, don't use upgrade-dependencies.

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

-- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.