is cabal-install buildable?

Evan Laforge qdunkan at gmail.com
Sun Mar 29 04:42:46 UTC 2020


I recently upgraded to ghc 8.8.3, thinking that since it's been around
8 months and 8.10 is already out, maybe things have stabilized enough.
But I immediately ran into confusing trouble with cabal-install.  It
seems like it's just not buildable since 8.8 came out.  Can this
really be true?

The reason is that from 2.4.0.0 onwards, it requires base <=4.13, and
8.8 uses base-4.13.  Oddly, 2.2.0.0 claims support up to base 5, but
actually not, because it also requires stm <2.5, and 8.8 uses stm 2.5,
and it's a bootlib.  I thought maybe the new nix-style build was
supposed to no longer require version matches for bootlibs, but since
`cabal v2-configure` fails I guess it must still have that
requirement.  In any case, my understanding is that linking to
different versions of bootlibs isn't a good idea anyway, because once
you have a dependency on the ghci api you're stuck.

I looked into how nixpkgs builds cabal-install, and it looks like it
disables version constraints, pulls a patch for hackage-security from
hvr's personal github.  So it is buildable, if you apply custom
patches.  Of course in the limit that's true of everything!

I guess we don't need source builds to work as long as someone
somewhere can figure out how to do the build and upload a binary, so I
downloaded the pre-built binary of 3.0.0.0 from
https://www.haskell.org/cabal/download.html, and it seemed to work at
first.  However, it couldn't build a particular package, and when I
tried to download and `cabal configure` it, I got a version conflict
which was not very clear, but the important line seems to be this:

[__1] rejecting: hlibgit2:setup.Cabal-3.0.1.0/installed-3.0...,
hlibgit2:setup.Cabal-3.0.0.0, hlibgit2:setup.Cabal-2.4.1.0,
hlibgit2:setup.Cabal-2.4.0.1, hlibgit2:setup.Cabal-2.4.0.0 (conflict: hlibgit2
=> hlibgit2:setup.Cabal>=1.10 && <1.25)

My best guess about what this means is that, while hlibgit2 has no
explicit dependency on Cabal (the library), it does have a Setup.hs,
which imports Distribution.Simple, and perhaps this creates a
dependency, and the ghc 8.8.3 has `Cabal-3.0.1.0` while cabal-install
was compiled against `Cabal-3.0.0.0`, and I vaguely remember if you
use a cabal-install whose Cabal version doesn't match the Cabal
version of the ghc you are using, it will appear to work, until it
doesn't, and then things will crash with confusing errors, or rebuild
constantly, or do something bad.

But of course I can't compile cabal-install against Cabal-3.0.1.0
because I can't build it at all.  Maybe it actually is important for
source builds to work!  It looks like I could downgrade to 8.8.1 and
maybe things would work.

Is this really the situation?  If it's not, where did I go wrong?  If
it is, how can we fix it?  Provided people agree it's a problem, but
if not, why not?  I seem to recall that just about every ghc release
has had this kind ghc-Cabal-cabal-install synchronization problem, and
it's one of the reasons I wait 6 months or so before upgrading.  But
of course that's not good for me or for ghc, because then I'm
reporting the bugs rather late.


More information about the Glasgow-haskell-users mailing list