New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solver wants to downgrade installed package needlessly #1864
Comments
btw, here's another curious case with todays hackage (and
vs.
|
@kosmikus fyi, I just re-tried the last command with the latest commit (kosmikus/cabal@a51b837) : http://lpaste.net/104324 So, if I understand it right, the problem seems to be |
@hvr Yes, see haskell/aeson#177. You might want to try this with kosmikus@814e493 instead (which should rebase properly on top of current |
@kosmikus indeed, with kosmikus/cabal@814e493 + kosmikus/cabal@a51b837 |
This adds a mechanism in the modular solver to store whether a flag is "strong" or "weak". A weak flag is deferred during solving, a strong flag is not. By default, flags are now weak unless they're manual. This is a change in behaviour, but I think it's probably the better default, because many automatic flags are used to figure out what's on the system rather than to impose hard constraints. There's a new flag --strong-flags that restores the old behaviour. I do not think such a global flag is particularly useful, but it may be of interest to compare build plans between the new and old behaviour. With these preparations, it's easy to make the distinction between strong and weak flags more sophisticated. We can either add more heuristics as to when flags should be treated as strong or weak, or we can add syntax to .cabal files that allows package authors to specify explicitly how they intend a flag to behave. This is related to various cabal-install issues, e.g. haskell#1831, haskell#1864, and haskell#1877.
Now that #1879 has been merged, I think we can close this. Feel free to reopen if you disagree. |
This adds a mechanism in the modular solver to store whether a flag is "strong" or "weak". A weak flag is deferred during solving, a strong flag is not. By default, flags are now weak unless they're manual. This is a change in behaviour, but I think it's probably the better default, because many automatic flags are used to figure out what's on the system rather than to impose hard constraints. There's a new flag --strong-flags that restores the old behaviour. I do not think such a global flag is particularly useful, but it may be of interest to compare build plans between the new and old behaviour. With these preparations, it's easy to make the distinction between strong and weak flags more sophisticated. We can either add more heuristics as to when flags should be treated as strong or weak, or we can add syntax to .cabal files that allows package authors to specify explicitly how they intend a flag to behave. This is related to various cabal-install issues, e.g. #1831, #1864, and #1877. (cherry picked from commit 3dcddea) Conflicts: cabal-install/Distribution/Client/Dependency.hs
This adds a mechanism in the modular solver to store whether a flag is "strong" or "weak". A weak flag is deferred during solving, a strong flag is not. By default, flags are now weak unless they're manual. This is a change in behaviour, but I think it's probably the better default, because many automatic flags are used to figure out what's on the system rather than to impose hard constraints. There's a new flag --strong-flags that restores the old behaviour. I do not think such a global flag is particularly useful, but it may be of interest to compare build plans between the new and old behaviour. With these preparations, it's easy to make the distinction between strong and weak flags more sophisticated. We can either add more heuristics as to when flags should be treated as strong or weak, or we can add syntax to .cabal files that allows package authors to specify explicitly how they intend a flag to behave. This is related to various cabal-install issues, e.g. #1831, #1864, and #1877. (cherry picked from commit 3dcddea) Conflicts: cabal-install/Distribution/Client/Dependency.hs cabal-install/Distribution/Client/Freeze.hs cabal-install/Distribution/Client/Setup.hs
@tibbe asked me to file this one. See
cabal-install
output at http://lpaste.net/104078 which shows the result for the following invocations:on a current GHC 7.8.2 install with an empty (user) package database. Note, adding
--constraint "bytestring installed"
to the last invocation would letcabal-install
find the same install-plan as for the 2nd invocation.The text was updated successfully, but these errors were encountered: