(Imported from Trac #884, reported by @nomeata on 2011-09-17)
in Debian, I have patched yesod-json-0.2.1 to depend on aeson instead of aeson-native, because we want only one aeson and blaze-textual package in Debian.
Still, if I use cabal install to install a package that depends on yesod-json, it wants to re-build yesod-json against the -native variants. It seems that cabal install does not take the actual dependencies of installed packages into account and uses the Hackage provided information for them as well.
What it should do instead is: If a dependency of some packages that is to be installed can be fulfilled by a locally installed package, and none of its dependencies (as known by ghc-pkg) have to be rebuild, then this package should be used. Only if the package in question has to be rebuild, the dependencies according to hackage should be taken into account.
The work around in Debian is to bump the version number, adding a vendor level (0.2.1.0.1), but it would be nice if this could be avoided.
(Imported comment by @dcoutts on 2011-09-17)
This is a known issue. It's a limitation of the current cabal-install dependency solver. It's not that it's taking the information from the wrong place, but as a simplifying assumption it assumes that if the versions are the same, they are the same. cabal-install will pick the installed instance rather than the source instance if its dependencies fall within the ranges that the solver determines are ok. In this case that doesn't happen because its got different dependencies.
The current solution is indeed to bump the version.
The current dev version of cabal-install has a way to ask explicitly to use the installed instance, ignoring the installed instance. Additionally, the new cabal-install solver will probably do a better job in cases like these. It considers each installed and source instances separately.
(Imported comment by @kosmikus on 2011-10-03)
The new solver will be in cabal-install-1.14, but it's not yet clear whether it will be the default. It can be activated using the --solver=modular flag. The new solver should indeed fix the problem.
(Imported comment by @kosmikus on 2012-03-03)
Also see #615.
(Imported comment by @kosmikus on 2012-03-05)
Also see #782.
Should work with the new solver.