Error in Installing Data.deriveTH
Hello all I am trying to install Data.deriveTH . When i tried cabal install derive , i got this error. ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install deriveResolving dependencies...<command line>: cannot satisfy -package Cabal-1.10.2.0: Cabal-1.10.2.0-072fce39d68f011c6a364057a3d15270 is unusable due to missing or recursive dependencies: containers-0.3.0.0-ee442470d8dcc9e45f31677c400c5379 (use -v for more information)cabal: Error: some packages failed to install:derive-2.5.4 depends on haskell-src-exts-1.11.1 which failed to install.haskell-src-exts-1.11.1 failed during the configure step. The exception was:ExitFailure 1 ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install haskell-src-extsResolving dependencies...<command line>: cannot satisfy -package Cabal-1.10.2.0: Cabal-1.10.2.0-072fce39d68f011c6a364057a3d15270 is unusable due to missing or recursive dependencies: containers-0.3.0.0-ee442470d8dcc9e45f31677c400c5379 (use -v for more information)cabal: Error: some packages failed to install:haskell-src-exts-1.11.1 failed during the configure step. The exception was:ExitFailure 1 ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install containersResolving dependencies...No packages to be installed. All the requested packages are already installed.If you want to reinstall anyway then use the --reinstall flag. I tried to resolve this issue on #haskell and i got suggestion that it was due to conflict in global and local namespace [ see here for more detail http://hpaste.org/51376 ]. One idea is i should wipe ~/.ghc and install all the libraries individually. Could some one please suggest if there is another idea to resolve this issue. Currently i have ghc-6.12.3 and installing ghc-7.0 will resolve the issue ? Thank you Mukesh Tiwari .
On Thursday 15 September 2011, 21:37:29, mukesh tiwari wrote:
I tried to resolve this issue on #haskell and i got suggestion that it was due to conflict in
global and local namespace [ see here for more detail http://hpaste.org/51376 ].
Yes.The containers in the global db is shadowed by the user containers.
One idea is i should wipe ~/.ghc and install all the libraries individually.
That'll work. If there are only few packages broken, unregistering only those could be less work. $ ghc-pkg check should indicate whether there's a chance that surgical removal of individual packages might be worthwhile. If the breakage is recent and only few packages are affected, it is, otherwise wiping out the entire user db would likely be simpler.
Could some one please suggest if there is another idea to resolve this issue.
There is no fundamentally different way, the only method to fix broken packages is to remove them. The only question is whether it's better to get completely rid of the entire user db [and if you have the bad luck of having breakage within the global db by doing global installs, you'd probably need an entire new ghc installation] or only of individual packages.
Currently i have ghc-6.12.3 and installing ghc-7.0 will resolve the issue ?
In a certain sense, yes. With a new version of ghc, you start with a clean slate without broken packages. However, you could pretty much introduce the same kind of breakage with that. Generally, it's a bad idea to reinstall any library that came with the ghc installation (there are some exceptions, e.g. installing a newer version of Cabal has a fair chance of not causing havoc). As rules of thumb, - don't mess with the global db, user installs only - don't install any library which already has a version in the global db[*] - be careful when upgrading any library, it could break everything depending on that. Of course, if you know what you're doing, there can be good reasons to break any of these rules, but if you don't know why it's right, it's probably wrong. Although it's tedious, checking all cabal install with a --dry-run first helps avoiding breakage. [*] and if you do, the more packages you have installed, the more likely it will break some of those.
Thank you for reply Daniel . I installed the ghc-7.2.1 but now running cabal install keys --dry-run -v gives error. One more thing i would like to know. Before installing any package , i should check its dependency and if it depends on any global namespace package [/usr/local/lib/ghc-7.2.1/package .conf.d ] so i should not install the global namespace package using cabal install <global-package> otherwise it will hide the global package. I should only install those packages which are not in global namespace. Am i correct ? Any idea how to remove this error . ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ ghcghc-7.2.1 ghci-7.2.1 ghc-pkg-7.2.1 ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ cabal install keys --dry-run -vcabal: The program ghc version >=6.4 is required but it could not be foundntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ cabal --vcabal-install version 0.10.2using version 1.10.2.0 of the Cabal libraryntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ ghc-pkg-7.2.1 list/usr/local/lib/ghc-7.2.1/package.conf.d Cabal-1.12.0 array-0.3.0.3 base-4.4.0.0 bin-package-db-0.0.0.0 binary-0.5.0.2 bytestring-0.9.2.0 containers-0.4.1.0 directory-1.1.0.1 extensible-exceptions-0.1.1.3 ffi-1.0 filepath-1.2.0.1 ghc-7.2.1 ghc-prim-0.2.0.0 haskell2010-1.1.0.0 haskell98-2.0.0.0 hoopl-3.8.7.1 hpc-0.5.1.0 integer-gmp-0.3.0.0 old-locale-1.0.0.3 old-time-1.0.0.7 pretty-1.1.0.0 process-1.1.0.0 rts-1.0 template-haskell-2.6.0.0 time-1.2.0.5 unix-2.5.0.0/home/ntro/.ghc/i386-linux-7.2.1/package.conf.d mtl-2.0.1.0 parsec-3.1.1 transformers-0.2.2.0ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ which ghc-7.2.1/usr/local/bin/ghc-7.2.1ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ echo $PATH/home/ntro/.cabal/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/gamesntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ which cabal/home/ntro/.cabal/bin/cabal On Fri, Sep 16, 2011 at 4:18 AM, Daniel Fischer < daniel.is.fischer@googlemail.com> wrote:
On Thursday 15 September 2011, 21:37:29, mukesh tiwari wrote:
I tried to resolve this issue on #haskell and i got suggestion that it was due to conflict in
global and local namespace [ see here for more detail http://hpaste.org/51376 ].
Yes.The containers in the global db is shadowed by the user containers.
One idea is i should wipe ~/.ghc and install all the libraries individually.
That'll work. If there are only few packages broken, unregistering only those could be less work.
$ ghc-pkg check
should indicate whether there's a chance that surgical removal of individual packages might be worthwhile. If the breakage is recent and only few packages are affected, it is, otherwise wiping out the entire user db would likely be simpler.
Could some one please suggest if there is another idea to resolve this issue.
There is no fundamentally different way, the only method to fix broken packages is to remove them. The only question is whether it's better to get completely rid of the entire user db [and if you have the bad luck of having breakage within the global db by doing global installs, you'd probably need an entire new ghc installation] or only of individual packages.
Currently i have ghc-6.12.3 and installing ghc-7.0 will resolve the issue ?
In a certain sense, yes. With a new version of ghc, you start with a clean slate without broken packages. However, you could pretty much introduce the same kind of breakage with that.
Generally, it's a bad idea to reinstall any library that came with the ghc installation (there are some exceptions, e.g. installing a newer version of Cabal has a fair chance of not causing havoc). As rules of thumb, - don't mess with the global db, user installs only - don't install any library which already has a version in the global db[*] - be careful when upgrading any library, it could break everything depending on that.
Of course, if you know what you're doing, there can be good reasons to break any of these rules, but if you don't know why it's right, it's probably wrong. Although it's tedious, checking all cabal install with a --dry-run first helps avoiding breakage.
[*] and if you do, the more packages you have installed, the more likely it will break some of those.
On Friday 16 September 2011, 13:55:25, mukesh tiwari wrote:
Thank you for reply Daniel . I installed the ghc-7.2.1 but now running cabal install keys --dry-run -v gives error. One more thing i would like to know. Before installing any package , i should check its dependency and if it depends on any global namespace package [/usr/local/lib/ghc-7.2.1/package .conf.d ] so i should not install the global namespace package using cabal install <global-package>
That depends on what you have in the global db, but it's a good rule of thumb.
otherwise it will hide the global package. I should only install those packages which are not in global namespace. Am i correct ?
The dependencies are checked by cabal, $ cabal install foo --dry-run should produce something like In order, the following would be installed (use -v for more details): bar-0.3.0.0 baz-1.0.5 foo-2.4.1 If any of the packages listed to be installed are already present, you *may* have a problem. If you already have the exact version of one of them, that's certainly a problem (cabal wouldn't want to reinstall the same version unless something's broken). If cabal wants to install a newer (or older) version of a package ghc itself depends on, that'll almost certainly break some things. If you don't change the global package db after the ghc-install, appearance in the global db is a simple criterion (though not perfect, installing a newer Cabal can be safe, and multiple versions of the same package in the user-db can also break things). In any case, cabal wanting to install a package you already have (and be it a different version) is cause for concern, one should check whether it looks reasonable. [The most common reason for cabal wanting to install a newer version of a present package is that some package you want to install depends on a newer version than you have. That's not a problem per se, but using two packages depending on different versions of the same package together usually doesn't work, so it might be good to recompile some of your packages against the newer version.]
Any idea how to remove this error .
ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ ghcghc-7.2.1 ghci-7.2.1 ghc-pkg-7.2.1 ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ cabal install keys --dry-run -v cabal: The program ghc version >=6.4 is required but it could not be found
Looks bad. The only idea I have is that it could be a PATH issue, your global db for 6.12.3 was under /var/lib, and your 7.2.1 lives under /usr/local, but it doesn't seem likely. However, does $ cabal install --with-compiler=/usr/local/bin/ghc-7.2.1 -v keys --dry-run work?
ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/Haskell$ which ghc-7.2.1 /usr/local/bin/ghc-7.2.1
Does there exist an unversioned ghc? What does $ which ghc print?
Two precautions: 1. "ghc-pkg check" is incomplete: It ignores shadowing problems, which are like 99% of the problems in practice. Skip "ghc-pkg check", go straight to "ghc -v" for the real report card. 2. "ghc-pkg unregister" has a long-standing bug. I have filed it as http://hackage.haskell.org/trac/ghc/ticket/5442 In practice, 99% of the time you use "--user", so the message for you is that before you order "ghc-pkg unregister --user blah", make sure you have a "blah" in the user database. Every time. (In particular, I have seen someone ordering the same "--user" command twice for no good reason, and the first time succeeded, and therefore the second time happily went ahead to mess with the global database.)
Thanks Daniel . It works. $ cabal install --with-compiler=/usr/local/bin/ghc-7.2.1 -v keys --dry-run
work?
ntro@ntro-HP-dx2480-MT-NA121PA:~$ cabal install
--with-compiler=/usr/local/bin/ghc-7.2.1 -v keys --dry-run Reading available packages... Resolving dependencies... In order, the following would be installed: contravariant-0.1.2.1 (new package) distributive-0.2.0.1 (new package) semigroups-0.8 (new package) comonad-1.1.1.1 (new package) semigroupoids-1.2.6 (new package) comonad-transformers-2.0.2 (new package) comonads-fd-2.0.2 (new package) data-lens-2.0.1 (new package) free-2.0.2 (new package) keys-2.1.1.1 (new package)
Does there exist an unversioned ghc? What does
$ which ghc
print?
It prints nothing . ntro@ntro-HP-dx2480-MT-NA121PA:~$ which ghc ntro@ntro-HP-dx2480-MT-NA121PA:~$ Looks bad. The only idea I have is that it could be a PATH issue, your global db for 6.12.3 was under /var/lib, and your 7.2.1 lives under /usr/local, but it doesn't seem likely. Precisely this was the issue . My /var/lib directory contains ghc-6.12.1 . ntro@ntro-HP-dx2480-MT-NA121PA:/var/lib$ ls gh* ghc-6.12.1: package.conf.d ghostscript: CMap fonts ntro@ntro-HP-dx2480-MT-NA121PA:/usr/local/lib$ ls ghc-7.2.1 python2.6 python2.7 python3.1 python3.2 site_ruby ntro@ntro-HP-dx2480-MT-NA121PA:/usr/local/lib$ ls ghc* array-0.3.0.3 directory-1.1.0.1 ghc-prim-0.2.0.0 hpc-0.5.1.0 libHSffi.a libHSrts_l.a libHSrts_thr_l.a runghc base-4.4.0.0 extensible-exceptions-0.1.1.3 ghc-split hsc2hs libHSffi-ghc7.2.1.so libHSrtsmain.a libHSrts_thr_p.a settings binary-0.5.0.2 filepath-1.2.0.1 ghc-usage.txt HSffi.o libHSffi_p.a libHSrts_p.a old-locale-1.0.0.3 template-haskell-2.6.0.0 bin-package-db-0.0.0.0 ghc haddock html libHSrts.a libHSrts_thr.a old-time-1.0.0.7 template-hsc.h bytestring-0.9.2.0 ghc-7.2.1 haskell2010-1.1.0.0 include libHSrts_debug.a libHSrts_thr_debug.a package.conf.d time-1.2.0.5 Cabal-1.12.0 ghci-usage.txt haskell98-2.0.0.0 integer-gmp-0.3.0.0 libHSrts_debug-ghc7.2.1.so libHSrts_thr_debug-ghc7.2.1.so pretty-1.1.0.0 unix-2.5.0.0 containers-0.4.1.0 ghc-pkg hoopl-3.8.7.1 latex libHSrts-ghc7.2.1.so libHSrts_thr-ghc7.2.1.so process-1.1.0.0 unlit . ntro@ntro-HP-dx2480-MT-NA121PA:/usr/local/bin$ ls ghc* ghc-7.2.1 ghci-7.2.1 ghc-pkg-7.2.1 ntro@ntro-HP-dx2480-MT-NA121PA:/usr/local/bin$ ls django-admin.py eggy eric4-compare eric4-doc eric4-pluginrepository eric4-re eric4-trpreviewer eric4-webbrowser ghc-pkg-7.2.1 hp2ps runghc spyder Editra eric4 eric4-configure eric4-editor eric4-pluginuninstall eric4-sqlbrowser eric4-uipreviewer ghc-7.2.1 haddock hpc runhaskell UTscapy Editra.pyw eric4-api eric4-diff eric4-plugininstall eric4-qregexp eric4-tray eric4-unittest ghci-7.2.1 haddock-ghc-7.2.1 hsc2hs scapy So should i delete ghc-6.12.1 from /var/lib and move the ghc-7.2.1 from /usr/local/lib to /var/lib to execute cabal install <pkg-name> -v --dry-run ? As /usr/local/bin is already in the path i don't need to move any files from here. Am i correct ? I am already on delay for my project so i don't want to take chances again if moving these files will again break something so i am asking you although i am pretty comfortable with $ cabal install --with-compiler=/usr/local/bin/ghc-7.2.1 -v keys --dry-run Regards Mukesh Tiwari
On Saturday 17 September 2011, 12:41:17, mukesh tiwari wrote:
Does there exist an unversioned ghc? What does
$ which ghc
print?
It prints nothing .
Okay, since cabal defaults to looking for plain "ghc" when no compiler is explicitly passed, that explains why it didn't work without --with-compiler Normally, when ghc is installed, it creates versionless symlinks to the actual scripts/binaries, so there should be symbolic links ghc, ghci, ghc-pkg to the versioned things (and haddock->haddock-ghc-7.2.1, runhaskell->runghc), many programmes expect unversioned tools by default. It might be that your install is broken, but probably creating the symlinks yourself (read the ln man-page and be careful when you create them) will be enough.
ntro@ntro-HP-dx2480-MT-NA121PA:/usr/local/bin$ ls ghc* ghc-7.2.1 ghci-7.2.1 ghc-pkg-7.2.1
Those should be linked to.
ntro@ntro-HP-dx2480-MT-NA121PA:/usr/local/bin$ ls django-admin.py eggy eric4-compare eric4-doc eric4-pluginrepository eric4-re eric4-trpreviewer eric4-webbrowser ghc-pkg-7.2.1 hp2ps runghc spyder Editra eric4 eric4-configure eric4-editor eric4-pluginuninstall eric4-sqlbrowser eric4-uipreviewer ghc-7.2.1 haddock hpc runhaskell UTscapy Editra.pyw eric4-api eric4-diff eric4-plugininstall eric4-qregexp eric4-tray eric4-unittest ghci-7.2.1 haddock-ghc-7.2.1 hsc2hs scapy
So should i delete ghc-6.12.1 from /var/lib
Optional. It shouldn't cause any problems (unless you need the space).
and move the ghc-7.2.1 from /usr/local/lib to /var/lib to execute cabal install <pkg-name> -v --dry-run ?
No, leave /usr/local/lib where it is, moving it would cause massive breakage. For example, /usr/bin/ghc-7.2.1 expects the libraries and binaries there. The only problem was that cabal looked for "ghc" which no longer exists on your path. That fact is somewhat dubious, as normally installing ghc creates the symlinks, but creating them is probably all that's needed if invoking ghc-7.2.1 works.
As /usr/local/bin is already in the path i don't need to move any files from here. Am i correct ?
Don't move anything. If your ghc-7.2.1 is broken, you will need to reinstall (that or another version), otherwise you can work with always using (and passing) the explicit version or, more conveniently, create the expected symlinks. Cheers, Daniel
On Thu, Sep 15, 2011 at 12:37 PM, mukesh tiwari
Hello all I am trying to install Data.deriveTH . When i tried cabal install derive , i got this error.
Many errors of this type can be avoided by using cabal-dev [1] instead of cabal-install for development -- cabal-dev keeps package databases for each project separate, although everything still also uses the global package db (so you shouldn't install anything there). cabal-install is still necessary (and ideal) for installing applications for use in normal activities, and for installing libraries into your user-package database for use in general ghci sessions. If nothing else, cabal-dev will ignore your user package db, which might be enough to get you going on whatever you're really doing instead of fixing your user package db right this moment :) --Rogan [1] cabal-dev: http://github.com/creswick/cabal-dev and on hackage.
ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install derive Resolving dependencies... <command line>: cannot satisfy -package Cabal-1.10.2.0: Cabal-1.10.2.0-072fce39d68f011c6a364057a3d15270 is unusable due to missing or recursive dependencies: containers-0.3.0.0-ee442470d8dcc9e45f31677c400c5379 (use -v for more information) cabal: Error: some packages failed to install: derive-2.5.4 depends on haskell-src-exts-1.11.1 which failed to install. haskell-src-exts-1.11.1 failed during the configure step. The exception was: ExitFailure 1
ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install haskell-src-exts Resolving dependencies... <command line>: cannot satisfy -package Cabal-1.10.2.0: Cabal-1.10.2.0-072fce39d68f011c6a364057a3d15270 is unusable due to missing or recursive dependencies: containers-0.3.0.0-ee442470d8dcc9e45f31677c400c5379 (use -v for more information) cabal: Error: some packages failed to install: haskell-src-exts-1.11.1 failed during the configure step. The exception was: ExitFailure 1
ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install containers Resolving dependencies... No packages to be installed. All the requested packages are already installed. If you want to reinstall anyway then use the --reinstall flag.
I tried to resolve this issue on #haskell and i got suggestion that it was due to conflict in
global and local namespace [ see here for more detail http://hpaste.org/51376 ]. One idea is i
should wipe ~/.ghc and install all the libraries individually. Could some one please suggest if
there is another idea to resolve this issue. Currently i have ghc-6.12.3 and installing
ghc-7.0 will resolve the issue ?
Thank you
Mukesh Tiwari
.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Albert Y. C. Lai -
Daniel Fischer -
mukesh tiwari -
Rogan Creswick