Re: [Haskell-cafe] Cabal message problem.
On 16.12.2010 15:40, Duncan Coutts wrote: On 16 December 2010 13:38, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: Maybe a flag ignore upper bounds and try with the latest for cabal would be a solution. Would that be hard to implement or easy? That suggestion has come up quite a few times. I think it's probably a good idea. But then Cabal-Install should report for which packages it had to extended version ranges and then it should prepare a set of e-mails to the maintainers with according patches to their Cabal files. :-) Maybe whenever a new GHC is released or a new set of Platform libraries, a script at Hackage should compile packages and send reports to the maintainers, either with suggestions which version dependency to relax, or with the compiler log, if the package could not be built. On the other hand, as maintainer of a lot of packages, I wished extending dependency ranges would be simpler. I often do not jump to every new GHC release, since this means recompiling all my packages and I may end up with touching a new bug in GHC, and then turning back to the old compiler version is difficult. Thus people often have to e-mail me, before I notice the need for a change myself. Then I extend the version range, bump the last digit in the version of my affected package, create a new darcs patch, upload to hackage, push a patch to darcs repository. Sure, I have a script for these steps, but consider this procedure for thirty packages for every GHC release! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thu, Dec 16, 2010 at 3:56 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: On Thu, Dec 16, 2010 at 3:48 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 December 2010 18:30, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: On Thu, Dec 16, 2010 at 2:59 PM, Ivan Lazar Miljenovic For example, now I have message as this when installing darcs. command line: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) The only way I know to get rid of this is to install Cabal-1.10.0.0 again. Then you could see that, it exists both global and user. $ ghc-pkg list /usr/local/lib/ghc-7.0.1/package.conf.d Cabal-1.10.0.0 array-0.3.0.2 base-4.3.0.0 bin-package-db-0.0.0.0 bytestring-0.9.1.8 containers-0.4.0.0 directory-1.1.0.0 extensible-exceptions-0.1.1.2 ffi-1.0 filepath-1.2.0.0 ghc-7.0.1 ghc-binary-0.5.0.2 ghc-prim-0.2.0.0 haskell2010-1.0.0.0 haskell98-1.1.0.0 hpc-0.5.0.6 integer-gmp-0.2.0.2 old-locale-1.0.0.2 old-time-1.0.0.6 pretty-1.0.1.2 process-1.0.1.4 random-1.0.0.3 rts-1.0 template-haskell-2.5.0.0 time-1.2.0.3 unix-2.4.1.0 /home/magicloud/.ghc/i386-linux-7.0.1/package.conf.d Cabal-1.10.0.0 HTTP-4000.0.10 binary-0.5.0.2 containers-0.3.0.0 dataenc-0.13.0.4 deepseq-1.1.0.2 directory-1.0.1.2 filepath-1.1.0.4 html-1.0.1.2 mmap-0.5.7 mtl-1.1.1.1 network-2.2.1.10 parsec-2.1.0.1 process-1.0.1.4 regex-base-0.93.2 regex-compat-0.93.1 regex-posix-0.94.4 tar-0.3.1.0 terminfo-0.3.1.3 text-0.11.0.1 utf8-string-0.3.6 zlib-0.5.2.0 You seem to have process installed twice... any reason for that? Possibly something has gone wrong with your user setup; try backing up your ~/.ghc, deleting it and try again. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com Yes. When I reinstalled Cabal to user space, it also installed process to user space again. And I also do not know why the global process does not fit it. But checking the package.conf.d shows: /usr/local/lib/ghc-7.0.1/package.conf.d/process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420.conf /home/magicloud/.ghc/i386-linux-7.0.1/package.conf.d/process-1.0.1.4-dbac0acfd36adbff7779acc361040910.conf The hash code is different. Also are the Cabal-1.10.0.0-*.conf. Really hoping cabal has some kind of way to ignore these version thing. -- 竹密岂妨流水过 山高哪阻野云飞 Oh, clean job around ~/.ghc and ~/.cabal has been done. No luck. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On 16 December 2010 19:06, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Oh, clean job around ~/.ghc and ~/.cabal has been done. No luck. Sounds like a dodgy GHC install then; I believe lispy on #haskell has reported similar problems. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thu, Dec 16, 2010 at 4:07 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 December 2010 19:06, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Oh, clean job around ~/.ghc and ~/.cabal has been done. No luck. Sounds like a dodgy GHC install then; I believe lispy on #haskell has reported similar problems. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com Ea, I just did ./configure make sudo make install in ghc 7 (stable)'s source tree. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
Magicloud Magiclouds magicloud.magiclouds at gmail.com writes: Really hoping cabal has some kind of way to ignore these version thing. +1, sort of. Really, when moving to ghc-7 I found the most annyoing thing is upper version bounds in cabal files. This makes cabal-install all too eager to downgrade libraries. E.g., ghc-7 comes with containers-0.4 but some cabal files require containers-0.3. This compiles, but presumably 0.4 is more efficient, and I'm losing that advantage. A more severe thing is that some A.cabal file might refer to package B in some version that does not compile with ghc-7, even if the author of B provided an update on hackage meanwhile. So actually what I do is cabal unpack and then remove all upper version bounds from the cabal file and then cabal install. I figure the above sounds a lot like why do we need to declare types for identifiers, it's just annoying when the types change. But: I'm always puzzled by build-dependencies like A = 3.4.5. With the major.minor.release scheme, a change in release means no API change (just bugfix), in minor means compatible extension of API, and only major changes can break the API. So, I could understand A = 3.* but anything that mentions minor and release numbers is really a quite pessimistic view of the world. Actually, I read A = 3.4.5 as my package depends on a bug in package A that was fixed in 3.4.6 J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thu, Dec 16, 2010 at 10:08:23AM +, Johannes Waldmann wrote: But: I'm always puzzled by build-dependencies like A = 3.4.5. With the major.minor.release scheme, a change in release means no API change (just bugfix), in minor means compatible extension of API, and only major changes can break the API. According to the official Haskell package versioning policy [1], given A.B.C it is only B that must change when breaking the API, and C must change when extending the API. If you download a package and it builds with newer versions of some packages than it says it allows, you ought to notify the maintainer so they can upload a new version with updated version constraints. -Brent [1] http://www.haskell.org/haskellwiki/Package_versioning_policy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thursday 16 December 2010 11:08:23, Johannes Waldmann wrote: But: I'm always puzzled by build-dependencies like A = 3.4.5. With the major.minor.release scheme, a change in release means no API change (just bugfix), in minor means compatible extension of API, and only major changes can break the API. So, I could understand A = 3.* but anything that mentions But according to http://www.haskell.org/haskellwiki/Package_versioning_policy the major version is A.B and C is the minor version, so A 3.5 is a reasonable constraint if the package is known to work with A-3.4.x but hasn't been tested with A = 3.5. The problem is that without upper bounds, things will break a lot when packages undergo API changes, but probably more often things will also work with the new API. So with upper bounds, you prevent breakage at the cost of preventing builds which would work. Maybe a flag ignore upper bounds and try with the latest for cabal would be a solution. Would that be hard to implement or easy? minor and release numbers is really a quite pessimistic view of the world. Actually, I read A = 3.4.5 as my package depends on a bug in package A that was fixed in 3.4.6 Or: it breaks with a bug introduced in 3.4.6 which hasn't yet been fixed. J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
Daniel Fischer daniel.is.fischer at googlemail.com writes: Maybe a flag ignore upper bounds and try with the latest for cabal +1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On 16 December 2010 13:38, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: The problem is that without upper bounds, things will break a lot when packages undergo API changes, but probably more often things will also work with the new API. So with upper bounds, you prevent breakage at the cost of preventing builds which would work. It's a tradeoff. One way to look at it is to say that upper bounds are just bad because there's a chance it might work if you were not using the bit of the API that changed. The other is to look at it from the point of users of the package and what kind of error messages they get. If there's no upper bound they get a random compile failure and they don't know what is wrong, who is to blame or how to fix it. If there is an upper bound then we at least have the chance to tell the users that the package does not work (or at least has not been tested by anyone) with that version of a dependency. We also have the possibility of picking different deps that are known to work. Yes, this stuff depends on having a reasonably clever dependency resolution algorithm, but I think we can improve in that area, there's plenty of ideas floating about, but less time to implement them. Maybe a flag ignore upper bounds and try with the latest for cabal would be a solution. Would that be hard to implement or easy? That suggestion has come up quite a few times. I think it's probably a good idea. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
Daniel Fischer daniel.is.fisc...@googlemail.com writes: Or: it breaks with a bug introduced in 3.4.6 which hasn't yet been fixed. This is an important point, I think: API breakages are not always intentional. Except for base, I generally don't specify upper bounds (well, maybe this is laziness on my part as well), unless I know it will break. On the other hand, I run a script that at regular intervals pulls a set of packages off Hackage and builds them, reporting any errors. This way, I'll hopefully be among the first to know if somebody upgrades a library that breaks any of my programs. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thursday 16 December 2010 15:40:37, Duncan Coutts wrote: On 16 December 2010 13:38, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: The problem is that without upper bounds, things will break a lot when packages undergo API changes, but probably more often things will also work with the new API. So with upper bounds, you prevent breakage at the cost of preventing builds which would work. It's a tradeoff. An unavoidable one, I think. And just for the record, I'm in favour of upper bounds. As the default behaviour, using known-to-work combinations of packages is the right thing. Maybe a flag ignore upper bounds and try with the latest for cabal would be a solution. Would that be hard to implement or easy? That suggestion has come up quite a few times. I think it's probably a good idea. So, would it be hard or easy? If it's not too hard, someone might try to implement it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal message problem.
Hi, I see this kind of information a lot when I using cabal to install package. Or sometimes same packages both exist in global and user space, which is a shadowed by message. How to resolve that? Thanks. Resolving dependencies... command line: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On 16 December 2010 13:35, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I see this kind of information a lot when I using cabal to install package. Or sometimes same packages both exist in global and user space, which is a shadowed by message. How to resolve that? Thanks. Resolving dependencies... command line: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) This means you built Cabal-1.10.0.0 against process-1.0.1.4, but have subsequently upgraded (or downgraded or uninstalled) process. As such, rebuild Cabal. ghc-pkg check will give you a list of all broken packages. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thu, Dec 16, 2010 at 10:55 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 December 2010 13:35, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I see this kind of information a lot when I using cabal to install package. Or sometimes same packages both exist in global and user space, which is a shadowed by message. How to resolve that? Thanks. Resolving dependencies... command line: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) This means you built Cabal-1.10.0.0 against process-1.0.1.4, but have subsequently upgraded (or downgraded or uninstalled) process. As such, rebuild Cabal. ghc-pkg check will give you a list of all broken packages. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com The annoying thing is, I did not upgrade Cabal. Cabal and process are now coming with ghc 7. But many cabal packages do not know about this, I am not sure if this is cabal's fault or the packages'. So when installing some packages by cabal, they install the same version of, for example, process again. Then other packages depend on Cabal will give out this error. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thu, Dec 16, 2010 at 2:24 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: On Thu, Dec 16, 2010 at 10:55 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 December 2010 13:35, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I see this kind of information a lot when I using cabal to install package. Or sometimes same packages both exist in global and user space, which is a shadowed by message. How to resolve that? Thanks. Resolving dependencies... command line: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) This means you built Cabal-1.10.0.0 against process-1.0.1.4, but have subsequently upgraded (or downgraded or uninstalled) process. As such, rebuild Cabal. ghc-pkg check will give you a list of all broken packages. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com The annoying thing is, I did not upgrade Cabal. Cabal and process are now coming with ghc 7. But many cabal packages do not know about this, I am not sure if this is cabal's fault or the packages'. So when installing some packages by cabal, they install the same version of, for example, process again. Then other packages depend on Cabal will give out this error. -- 竹密岂妨流水过 山高哪阻野云飞 And, sure, I could reinstall Cabal. Then things seem fine. But it is weird. I have to have the same packages installed at two places of the system. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On 16 December 2010 17:26, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: And, sure, I could reinstall Cabal. Then things seem fine. But it is weird. I have to have the same packages installed at two places of the system. What makes you say that? Does ghc-pkg list show it twice? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thu, Dec 16, 2010 at 2:59 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 December 2010 17:26, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: And, sure, I could reinstall Cabal. Then things seem fine. But it is weird. I have to have the same packages installed at two places of the system. What makes you say that? Does ghc-pkg list show it twice? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com Yep. For example, now I have message as this when installing darcs. command line: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) The only way I know to get rid of this is to install Cabal-1.10.0.0 again. Then you could see that, it exists both global and user. $ ghc-pkg list /usr/local/lib/ghc-7.0.1/package.conf.d Cabal-1.10.0.0 array-0.3.0.2 base-4.3.0.0 bin-package-db-0.0.0.0 bytestring-0.9.1.8 containers-0.4.0.0 directory-1.1.0.0 extensible-exceptions-0.1.1.2 ffi-1.0 filepath-1.2.0.0 ghc-7.0.1 ghc-binary-0.5.0.2 ghc-prim-0.2.0.0 haskell2010-1.0.0.0 haskell98-1.1.0.0 hpc-0.5.0.6 integer-gmp-0.2.0.2 old-locale-1.0.0.2 old-time-1.0.0.6 pretty-1.0.1.2 process-1.0.1.4 random-1.0.0.3 rts-1.0 template-haskell-2.5.0.0 time-1.2.0.3 unix-2.4.1.0 /home/magicloud/.ghc/i386-linux-7.0.1/package.conf.d Cabal-1.10.0.0 HTTP-4000.0.10 binary-0.5.0.2 containers-0.3.0.0 dataenc-0.13.0.4 deepseq-1.1.0.2 directory-1.0.1.2 filepath-1.1.0.4 html-1.0.1.2 mmap-0.5.7 mtl-1.1.1.1 network-2.2.1.10 parsec-2.1.0.1 process-1.0.1.4 regex-base-0.93.2 regex-compat-0.93.1 regex-posix-0.94.4 tar-0.3.1.0 terminfo-0.3.1.3 text-0.11.0.1 utf8-string-0.3.6 zlib-0.5.2.0 -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On 16 December 2010 18:30, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: On Thu, Dec 16, 2010 at 2:59 PM, Ivan Lazar Miljenovic For example, now I have message as this when installing darcs. command line: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) The only way I know to get rid of this is to install Cabal-1.10.0.0 again. Then you could see that, it exists both global and user. $ ghc-pkg list /usr/local/lib/ghc-7.0.1/package.conf.d Cabal-1.10.0.0 array-0.3.0.2 base-4.3.0.0 bin-package-db-0.0.0.0 bytestring-0.9.1.8 containers-0.4.0.0 directory-1.1.0.0 extensible-exceptions-0.1.1.2 ffi-1.0 filepath-1.2.0.0 ghc-7.0.1 ghc-binary-0.5.0.2 ghc-prim-0.2.0.0 haskell2010-1.0.0.0 haskell98-1.1.0.0 hpc-0.5.0.6 integer-gmp-0.2.0.2 old-locale-1.0.0.2 old-time-1.0.0.6 pretty-1.0.1.2 process-1.0.1.4 random-1.0.0.3 rts-1.0 template-haskell-2.5.0.0 time-1.2.0.3 unix-2.4.1.0 /home/magicloud/.ghc/i386-linux-7.0.1/package.conf.d Cabal-1.10.0.0 HTTP-4000.0.10 binary-0.5.0.2 containers-0.3.0.0 dataenc-0.13.0.4 deepseq-1.1.0.2 directory-1.0.1.2 filepath-1.1.0.4 html-1.0.1.2 mmap-0.5.7 mtl-1.1.1.1 network-2.2.1.10 parsec-2.1.0.1 process-1.0.1.4 regex-base-0.93.2 regex-compat-0.93.1 regex-posix-0.94.4 tar-0.3.1.0 terminfo-0.3.1.3 text-0.11.0.1 utf8-string-0.3.6 zlib-0.5.2.0 You seem to have process installed twice... any reason for that? Possibly something has gone wrong with your user setup; try backing up your ~/.ghc, deleting it and try again. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal message problem.
On Thu, Dec 16, 2010 at 3:48 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 December 2010 18:30, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: On Thu, Dec 16, 2010 at 2:59 PM, Ivan Lazar Miljenovic For example, now I have message as this when installing darcs. command line: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) The only way I know to get rid of this is to install Cabal-1.10.0.0 again. Then you could see that, it exists both global and user. $ ghc-pkg list /usr/local/lib/ghc-7.0.1/package.conf.d Cabal-1.10.0.0 array-0.3.0.2 base-4.3.0.0 bin-package-db-0.0.0.0 bytestring-0.9.1.8 containers-0.4.0.0 directory-1.1.0.0 extensible-exceptions-0.1.1.2 ffi-1.0 filepath-1.2.0.0 ghc-7.0.1 ghc-binary-0.5.0.2 ghc-prim-0.2.0.0 haskell2010-1.0.0.0 haskell98-1.1.0.0 hpc-0.5.0.6 integer-gmp-0.2.0.2 old-locale-1.0.0.2 old-time-1.0.0.6 pretty-1.0.1.2 process-1.0.1.4 random-1.0.0.3 rts-1.0 template-haskell-2.5.0.0 time-1.2.0.3 unix-2.4.1.0 /home/magicloud/.ghc/i386-linux-7.0.1/package.conf.d Cabal-1.10.0.0 HTTP-4000.0.10 binary-0.5.0.2 containers-0.3.0.0 dataenc-0.13.0.4 deepseq-1.1.0.2 directory-1.0.1.2 filepath-1.1.0.4 html-1.0.1.2 mmap-0.5.7 mtl-1.1.1.1 network-2.2.1.10 parsec-2.1.0.1 process-1.0.1.4 regex-base-0.93.2 regex-compat-0.93.1 regex-posix-0.94.4 tar-0.3.1.0 terminfo-0.3.1.3 text-0.11.0.1 utf8-string-0.3.6 zlib-0.5.2.0 You seem to have process installed twice... any reason for that? Possibly something has gone wrong with your user setup; try backing up your ~/.ghc, deleting it and try again. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com Yes. When I reinstalled Cabal to user space, it also installed process to user space again. And I also do not know why the global process does not fit it. But checking the package.conf.d shows: /usr/local/lib/ghc-7.0.1/package.conf.d/process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420.conf /home/magicloud/.ghc/i386-linux-7.0.1/package.conf.d/process-1.0.1.4-dbac0acfd36adbff7779acc361040910.conf The hash code is different. Also are the Cabal-1.10.0.0-*.conf. Really hoping cabal has some kind of way to ignore these version thing. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
