Changed dependencies in locally installed packages ignord #874

Closed
bos opened this Issue May 24, 2012 · 5 comments

Projects

None yet

2 participants

@bos
Contributor
bos commented May 24, 2012

(Imported from Trac #884, reported by @nomeata on 2011-09-17)

Hello,

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.

@kosmikus kosmikus was assigned May 24, 2012
@bos
Contributor
bos commented May 24, 2012

(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.

@bos
Contributor
bos commented May 24, 2012

(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.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @kosmikus on 2012-03-03)

Also see #615.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @kosmikus on 2012-03-05)

Also see #782.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @kosmikus on 2012-03-05)

Should work with the new solver.

@bos bos closed this May 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment