Hi, I just get this output from cabal: cabal install leksah Resolving dependencies... cabal: dependencies conflict: ghc-7.0.4 requires array ==0.3.0.3 however array-0.3.0.3 was excluded because ghc-7.0.4 requires array ==0.3.0.2 How can it be that the same package (ghc-7.0.4) asks for two different versions (array 0.3.0.3 / 0.3.0.2) excluding each other? claudio
You probably have some packages of yours installed as user and some others globally. Have a look at: http://www.haskell.org/cabal/FAQ.html#dependencies-conflict I recommend that as soon as you have a running Haskell Platform to always install new packages with cabal install ... --user Thomas Am Sonntag, den 23.10.2011, 13:27 +0200 schrieb Claudio Nieder:
Hi,
I just get this output from cabal:
cabal install leksah Resolving dependencies... cabal: dependencies conflict: ghc-7.0.4 requires array ==0.3.0.3 however array-0.3.0.3 was excluded because ghc-7.0.4 requires array ==0.3.0.2
How can it be that the same package (ghc-7.0.4) asks for two different versions (array 0.3.0.3 / 0.3.0.2) excluding each other?
claudio
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On Mon, Oct 24, 2011 at 2:17 AM, Thomas Friedrich <info@suud.de> wrote:
You probably have some packages of yours installed as user and some others globally. Have a look at:
http://www.haskell.org/cabal/FAQ.html#dependencies-conflict
I recommend that as soon as you have a running Haskell Platform to always install new packages with cabal install ... --user
While I arrived at the same conclusion independently, it seems to contradict the recommendation found at http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-.... But every time I try shifting between using the package manager (which uses cabal install with a system-wide database) and building my own packages, things break in horrible ways. Running cabal as root just means the problems occur between root's private package db and the system one, breaking things in even more interesting ways. <mike
Here's the advice I use on when to use what to install cabal packages: http://www.vex.net/~trebla/haskell/sicp.xhtml I think it's a bit overcautious, but rather that than the alternative. It's worth a read even if you don't follow the advice in the end. On Mon, Oct 24, 2011 at 9:51 PM, Mike Meyer <mwm@mired.org> wrote:
On Mon, Oct 24, 2011 at 2:17 AM, Thomas Friedrich <info@suud.de> wrote:
You probably have some packages of yours installed as user and some others globally. Have a look at:
http://www.haskell.org/cabal/FAQ.html#dependencies-conflict
I recommend that as soon as you have a running Haskell Platform to always install new packages with cabal install ... --user
While I arrived at the same conclusion independently, it seems to contradict the recommendation found at http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-....
But every time I try shifting between using the package manager (which uses cabal install with a system-wide database) and building my own packages, things break in horrible ways. Running cabal as root just means the problems occur between root's private package db and the system one, breaking things in even more interesting ways.
<mike
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On 25 October 2011 09:34, Ben Millwood <haskell@benmachine.co.uk> wrote:
Here's the advice I use on when to use what to install cabal packages:
http://www.vex.net/~trebla/haskell/sicp.xhtml
I think it's a bit overcautious, but rather that than the alternative. It's worth a read even if you don't follow the advice in the end.
I think the choice of which advice to follows boil down to something rather simple: how good is the quality of Haskell packages in your distribution? My main experience at the time of writing my blog post was with Gentoo, which had rather good support, especially for the popular packages (might be a bit behind for not-so-common ones, but easily bumped if a user asked it). Quite a few problems then arose with users trying to mix-and-match system packages with user packages, when there was no need to do so. But in distributions that _don't_ have good Haskell support (e.g. I'm currently using Exherbo, and mix-and-match system and user packages because the system packages are rather limited; I've been meaning to try and add native Cabal support to the package manager to fix this for about a year now, but I'm not looking forward to hacking in C++ :p), then it may make more sense to use user-packages only... _if_ you understand the limitations this has. Package managers for distributions are typically better suited for resolving dependencies (especially if you give them specific information like "containers isn't meant to be user-upgradeable" and which version of containers comes with which version of GHC) and are able to uninstall packages, which cabal-install can't do yet. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
Hi, many thanks to all who answered my post, I learned a lot by reading them and the referenced web pages.
You probably have some packages of yours installed as user and some others globally. Have a look at:
This explains well why I got the strange error.
I recommend that as soon as you have a running Haskell Platform to always install new packages with cabal install ... --user
This is actually what I did. But this is not fool proof (and I was here the fool), because I can still do harm by asking cabal to install packages - which get registered in the user package db - that are part of ghc - thus registered also in the global db. So I decided now to go the all global route - which is not really global as I did install ghc anyway in my own directory - so that there is only one package db. For the sake of anybody stumbling over this thread in the future, this is what I do now: # Fetch and untar both ghc and cabal-install, install ghc cd /tmp curl -O http://www.haskell.org/ghc/dist/7.0.4/ghc-7.0.4-x86_64-apple-darwin.tar.b z2 curl -O http://www.haskell.org/cabal/release/cabal-install-0.10.2/cabal-install-0 .10.2.tar.gz tar xf ghc-7.0.4-x86_64-apple-darwin.tar.bz2 tar xf cabal-install-0.10.2.tar.gz cd /tmp/ghc-7.0.4 ./configure --prefix=/Users/claudio/Haskell/GHC make install # Modify the path in bootstrap.sh for my own "global" directory # and execute it with the --global option so that all packages it # installs go to the global package db. cd /tmp/cabal-install-0.10.2 perl -i -pe 's"/usr/local"\$HOME/Haskell/GHC"' bootstrap.sh chmod u+rwx bootstrap.sh ./bootstrap.sh --global PATH=$PATH:$HOME/Haskell/GHC/bin cabal update At this point cabal has created its config file $HOME/.cabal/config which I modify so that cabal defaults to global but uses my own directory by applying these changes: $ diff -d config.orig config 31c31 < -- user-install: True ---
user-install: False 68c68 < -- prefix: /usr/local
prefix: /Users/claudio/Haskell/GHC
claudio
On Wed, Oct 26, 2011 at 1:26 AM, Claudio Nieder <private@claudio.ch> wrote:
Hi,
many thanks to all who answered my post, I learned a lot by reading them and the referenced web pages.
You probably have some packages of yours installed as user and some others globally. Have a look at:
This explains well why I got the strange error.
I recommend that as soon as you have a running Haskell Platform to always install new packages with cabal install ... --user
This is actually what I did. But this is not fool proof (and I was here the fool), because I can still do harm by asking cabal to install packages - which get registered in the user package db - that are part of ghc - thus registered also in the global db.
So I decided now to go the all global route - which is not really global as I did install ghc anyway in my own directory - so that there is only one package db.
I don't think this is foolproof, either. Correct me, anyone else, if I'm wrong, but in some cases cabal will want to rebuild your packages that came with GHC; sometimes this can involve breaking a package that cannot be rebuilt (e.g. the ghc package depends on the directory package, if cabal tried to reinstall that for some reason, the ghc package would be broken). The advantage of doing everything in the user space is that it's relatively less painful to undo mistakes, because you can just unregister clones; you might break some packages, but they will all be from Hackage and hence in principle replaceable.
On 11-10-26 10:40 AM, Ben Millwood wrote:
I don't think this is foolproof, either. Correct me, anyone else, if I'm wrong, but in some cases cabal will want to rebuild your packages that came with GHC; sometimes this can involve breaking a package that cannot be rebuilt (e.g. the ghc package depends on the directory package, if cabal tried to reinstall that for some reason, the ghc package would be broken).
Correct, and my http://www.vex.net/~trebla/haskell/sicp.xhtml has an example in the pigeon drop con section. That example is difficult to reproduce today, as Hackage hosts far newer versions now than assumed back then. But you should still read it for the working principle. (Once upon a time, when hackage frontier versions matched what I wrote, it was easy to reproduce.) To reproduce the scenerio today, at the time of writing, try this: GHC version 7.2.1, comes with ghc-7.2.1 template-haskell-2.6.0.0 containers-0.4.1.0 where ghc depends on template-haskell depends on containers. At the time of writing, Hackage frontier has QuickCheck-2.4.1.1 template-haskell-2.6.0.0 containers-0.4.2.0 where QuickCheck depends on template-haskell depends on containers. At the bottom of the food chain (containers), Hackage frontier is newer than what we have installed, but at middle parts of the food chain (template-haskell), Hackage frontier matches installed versions. All players are ready for the pigeon drop con! An upgrade whore comes along to upgrade containers like it is a ground-breaking change: cabal install --global containers Then a benign admin comes along to install QuickCheck because it's needed and it hasn't been installed: cabal install --global QuickCheck (triggers replacing template-haskell-2.6.0.0) The earth-shattering disaster is complete. ghc-7.2.1 is hosed. $ ghc -v Glasgow Haskell Compiler, Version 7.2.1, stage 2 booted by GHC version 6.12.1 [...] package ghc-7.2.1-b200b39a49432181058dc1bbf8fabb95 is unusable due to missing or recursive dependencies: template-haskell-2.6.0.0-cd296972708e01dd01d7d840ce1d5d71 \∩/
participants (6)
-
Albert Y. C. Lai -
Ben Millwood -
Claudio Nieder -
Ivan Lazar Miljenovic -
Mike Meyer -
Thomas Friedrich