On Thu, Dec 16, 2010 at 2:24 PM, Magicloud Magiclouds wrote:

On Thu, Dec 16, 2010 at 10:55 AM, Ivan Lazar Miljenovic wrote:

...

On 16 December 2010 13:35, Magicloud Magiclouds 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.Miljenovic@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. -- 竹密岂妨流水过 山高哪阻野云飞

On Thu, Dec 16, 2010 at 2:59 PM, Ivan Lazar Miljenovic wrote:

On 16 December 2010 17:26, Magicloud Magiclouds 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.Miljenovic@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 -- 竹密岂妨流水过 山高哪阻野云飞

On Thu, Dec 16, 2010 at 3:48 PM, Ivan Lazar Miljenovic wrote:

On 16 December 2010 18:30, Magicloud Magiclouds 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.Miljenovic@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. -- 竹密岂妨流水过 山高哪阻野云飞

On 16 December 2010 19:06, Magicloud Magiclouds 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.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Magicloud Magiclouds 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.

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.

On 16 December 2010 13:38, Daniel Fischer 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

On 16.12.2010 15:40, Duncan Coutts wrote:

On 16 December 2010 13:38, Daniel Fischer 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!