Skip to content
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

Closed
hvr opened this issue May 13, 2014 · 6 comments
Closed

Solver wants to downgrade installed package needlessly #1864

hvr opened this issue May 13, 2014 · 6 comments
Assignees

Comments

@hvr
Copy link
Member

hvr commented May 13, 2014

@tibbe asked me to file this one. See cabal-install output at http://lpaste.net/104078 which shows the result for the following invocations:

# 1st (fails due to backjumps exhaustion)
$ cabal install aeson http-streams --dry

# 2nd (succeeds with sensible install plan)
$ cabal install http-streams aeson --dry

# 3rd (results in --force-install plan)
$ cabal install aeson http-streams --max-backjumps=500 --dry

on a current GHC 7.8.2 install with an empty (user) package database. Note, adding --constraint "bytestring installed"to the last invocation would let cabal-install find the same install-plan as for the 2nd invocation.

@hvr
Copy link
Member Author

hvr commented May 13, 2014

btw, here's another curious case with todays hackage (and cabal-install-1.20.0.1):

$ cabal install http-streams --dry 
Resolving dependencies...
In order, the following would be installed:
bytestring-0.10.2.0 (latest: 0.10.4.0) (new version)
base64-bytestring-1.0.0.1 (new package)
dlist-0.7.0.1 (new package)
mtl-2.1.3.1 (latest: 2.2.0.1) (new package)
primitive-0.5.2.1 (new package)
syb-0.4.1 (new package)
text-1.0.0.1 (latest: 1.1.1.2) (new package)
blaze-builder-0.3.3.2 (new package)
hashable-1.2.1.0 (new package)
case-insensitive-1.2.0.0 (new package)
parsec-3.1.5 (new package)
scientific-0.2.0.2 (new package)
attoparsec-0.11.3.0 (new package)
unix-2.7.0.1 (reinstall) changes: bytestring-0.10.4.0 -> 0.10.2.0
directory-1.2.1.0 (reinstall)
network-2.4.2.3 (latest: 2.5.0.0) (new package)
HsOpenSSL-0.10.4 (new package)
process-1.2.0.0 (reinstall)
unordered-containers-0.2.4.0 (new package)
http-common-0.7.1.1 (new package)
vector-0.10.9.1 (new package)
aeson-0.7.0.3 (new package)
zlib-0.5.4.1 (new package)
zlib-bindings-0.1.1.5 (new package)
io-streams-1.1.4.3 (new package)
openssl-streams-1.1.0.0 (new package)
http-streams-0.7.1.1 (new package)
Warning: The following packages are likely to be broken by the reinstalls:
haskell98-2.0.0.3
ghc-7.8.2
Cabal-1.18.1.3
bin-package-db-0.0.0.0
hpc-0.6.0.1
Use --force-reinstalls if you want to install anyway.

vs.

$ cabal install http-streams --constraint 'bytestring installed' --dry 
Resolving dependencies...
In order, the following would be installed (use -v for more details):
base64-bytestring-1.0.0.1
dlist-0.7.0.1
mtl-2.1.3.1 (latest: 2.2.0.1)
primitive-0.5.2.1
syb-0.4.1
text-1.1.1.2
blaze-builder-0.3.3.2
hashable-1.2.1.0
case-insensitive-1.2.0.0
parsec-3.1.5
network-2.4.2.3 (latest: 2.5.0.0)
HsOpenSSL-0.10.4
scientific-0.2.0.2
attoparsec-0.11.3.0
unordered-containers-0.2.4.0
http-common-0.7.1.1
vector-0.10.9.1
aeson-0.7.0.3
zlib-0.5.4.1
zlib-bindings-0.1.1.5
io-streams-1.1.4.3
openssl-streams-1.1.0.0
http-streams-0.7.1.1

@hvr
Copy link
Member Author

hvr commented May 19, 2014

@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 aeson's new-bytestring-builder flag

@kosmikus
Copy link
Contributor

@hvr Yes, see haskell/aeson#177. You might want to try this with kosmikus@814e493 instead (which should rebase properly on top of current master and also on top of kosmikus@a51b837).

@hvr
Copy link
Member Author

hvr commented May 19, 2014

@kosmikus indeed, with kosmikus/cabal@814e493 + kosmikus/cabal@a51b837 cabal install http-streams works much better

kosmikus added a commit to kosmikus/cabal that referenced this issue May 19, 2014
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.
@kosmikus
Copy link
Contributor

@hvr Thanks for testing. I've slightly updated the change and submitted it as pull request #1879.

@kosmikus
Copy link
Contributor

Now that #1879 has been merged, I think we can close this. Feel free to reopen if you disagree.

kosmikus added a commit that referenced this issue May 23, 2014
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
kosmikus added a commit that referenced this issue May 23, 2014
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants