-
Notifications
You must be signed in to change notification settings - Fork 711
containers test suite no longer builds with 1.20 #1806
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
Comments
Here are the
Here are the packages that are installed in the sandbox:
|
Both the top-down and the modular solver has the issue, so it's likely due to how the solver is invoked. |
It would be enlightening to see the |
This builds and tests containers with GHC 7.0, 7.4, 7.6, 7.8, and GHC HEAD (Once haskell/cabal#1806 is fixed we can use CABALVER=1.20 w/ GHCVER=7.8.2)
It may be useful as a debug mechanism to add a way to dump the inputs to the solver. In this case we'd want to compare 1.18 with 1.20, but one can imagine other use cases (like why does freeze behave oddly, answer because we can see that we're passing the solver strange input). |
@dcoutts I agree. I think I've asked for that feature a couple of days ago. Preferably we'd dump the constraints and preferences (separately) when |
Here's the, slightly cleaned up, output using @kosmikus's patch on HEAD (which should have the same behavior as 1.20):
"Dependency tree exhaustively searched." is the last line before cabal exits. |
I've backported the debugging output to 1.18. Here's the result:
So the difference is that in 1.18 we continued (and subsequently succeeded) after dependency resolution failed. In 1.20 we stop and thus fail. |
The constraints output doesn't seem to be working, it doesn't contains any of the package's dependencies (and no dependencies of dependencies and so on.) |
Right. So the situation for the solver hasn't actually changed. There was a fallback for For the dependency solver to work in this situation, we must either implement private dependencies, or relax some of the underlying assumptions in a different way. If we had separate units, would it then just work? We'd install the new containers first, then build |
I think that this was caused by #1565. |
@kosmikus I think it would just work if we had separate units. In this case the test suite doesn't even depend on the library (instead it just uses the same source dir), so with separate units we'd have test-suite -> ChasingBottoms -> containers. @23Skidoo I think we should, reluctantly, revert #1565 (unless it can be fixed somehow.) The cost of having none of our core libraries' test suites not work is too high. |
Another option might be to allow a third solver called "dumb" that does what configure used to do when the solver failed. |
Let's revert it in the 1.20 branch and try to come up with a better fix for 1.22. |
Agreed.
|
Fixed in 8dd4441 on the 1.20 branch. Since the 1.20 branch will eventually be merged back into master again this means that if we do nothing we'll eventually revert to the old behavior in 1.22. |
...hoping that haskell/cabal#1806 has been resolved for good
This used to work in 1.18:
With 1.20 this fails with:
None of the changes under
cabal-install/Distribution/Client/Dependency
since 1.18 looks suspicious, so the culprit is likely elsewhere. The only other thing that I can think of that touched dependency related things was the ability to pass the exact package hash when configuring, but I don't know if we use that functionality internally./cc @kosmikus @dcoutts
The text was updated successfully, but these errors were encountered: