Queue Sheet Hackage Build Failure (Part 2)
I decided to look a bit deeper into the Queue Sheet Hackage build failure that occurred yesterday. Before starting, I ran my test suite using Cabal and confirmed that there are no failures. I then installed GHC 8.10.2 and (unsuccessfully) attempted to reproduce the error locally.
First, I tried building Queue Sheet with the following command:
$ cabal v2-build --with-ghc ghc-8.10.2 | tee ghc-8.10.2.logThe build succeeds, using the following dependency versions. The latest version of Ginger is used, which works with the latest version of Aeson, so it did not fail like the Hackage build. I noticed that text-1.2.5.0 was used, which is newer than the GHC boot library version for GHC 8.10.2.
| aeson-2.0.3.0 | latest |
| ansi-wl-pprint-0.6.9 | latest |
| base-4.14.1.0 | boot |
| bytestring-0.10.10.0 | boot |
| directory-1.3.6.0 | boot |
| filepath-1.4.2.1 | boot |
| ginger-0.10.4.0 | latest |
| optparse-applicative-0.16.1.0 | |
| process-1.6.9.0 | boot |
| scientific-0.3.7.0 | latest |
| text-1.2.5.0 | newer than boot |
| transformers-0.5.6.2 | boot |
| ttc-1.1.1.1 | latest |
| vector-0.12.3.1 | latest |
| yaml-0.11.8.0 | latest |
To understand the version selections better, I turned up the verbosity by using the following command:
$ cabal v2-build --with-ghc ghc-8.10.2 --verbose=3 \
| tee ghc-8.10.2-verbose.logThe build succeeds, and I confirmed that the dependency versions in
the verbose log match those listed above. The verbose log lists every
step performed in the selection of package versions. I discovered that
ginger-0.10.4.0
was initially rejected because containers-0.6.2.1
is the GHC
boot library version while that version of Ginger has
>=0.6.4 && <0.7 constraints.
I found that containers-0.6.5.1
(the latest version) was selected. Though the constraints do not seem to
require it, this selection seems to result in the selection of newer
versions of the binary and text packages.
I am note sure how Hackage is building the package. Such information is unfortunately not part of the build report. I tried searching for hints in the hackage-server source code but did not have any luck. In attempts to recreate the error that I see on Hackage, I tried building with the following options, but every build succeeded.
--count-conflicts--fine-grained-conflicts--independent-goals--minimize-conflict-set--reorder-goals--shadow-installed-packages
Perhaps I will have a good idea if I think about something else for a while…