
Ivan Lazar Miljenovic schrieb:
Henning Thielemann
writes: This makes sense. It would be certainly better if cabal-install would alert about the found inconsistency instead of trying to fix it. Then there might an additional cabal-install flag, that makes cabal-install prefer the output of ghc-pkg over the hackage database 00-index.tar in case of inconsistencies.
What do you mean by "prefer the output of ghc-pkg over the hackage database"? If there is a broken/invalid dependency chain, then dependencies _have_ to be rebuilt to fix it. ghc-pkg, however, doesn't say _how_ those packages where built or from where.
Could the problem also be solved by changing the version of packages with locally modified cabal files from a.b.c.d to a.b.c.d+1 ?
No, since it will always prefer the highest version, and if its the one that's broken then it will just complain that that package doens't exist and will refuse to build what you want.
I meant it the other way round: Given that package X-a.b.c.d does not compile due to dependencies that turn out to be too restricted, then I could relax the dependency version bounds in X.cabal. If I also increase X's version to a.b.c.d+1, then cabal-install should be happy.