Cabal/Cabal-syntax split patches

ci/MakeConstraints.hs

@@ -19,7 +19,6 @@ bootPkgs = S.fromList
   [ "base"
   , "template-haskell"
   , "time"
-  , "Cabal"
   , "ghc"
   , "ghc-prim"
   , "integer-gmp"
@@ -27,6 +26,9 @@ bootPkgs = S.fromList
   , "text"
   , "binary"
   , "ghc-bignum"
+  -- Cabal is not in this list because of complications with the Cabal/Cabal-syntax
+  -- upgrade. See !205 and https://github.com/haskell/cabal/issues/7974
+  -- , "Cabal"
   ]
 
 allowNewer :: S.Set Cabal.PackageName -> Doc

[Ryan Scott]

I'm not sure how to feel about removing Cabal from the list of dependencies to mark as allow-newer. Generally speaking, I think we should try to build with the versions of libraries that come bundled with GHC HEAD, and Cabal is one such library that is bundled with GHC. It's true that you can re-install it, but will result in a lot of wasted build time. Moreover, building with the bundled versions of libraries can sometimes uncover legitimate build issues, which would be preferable to address in head.hackage when they arise.

That being said, it may not be possible to do this at the moment, since there is the matter of the strange Agda bug observed in !205 (comment 408891). In that case, I propose that we:

1. Leave a comment in this file explaining why Cabal is absent from this list, and
2. Open an issue about the Agda bug so that we don't forget to investigate it. If we resolve that bug, we can attempt to add Cabal make to the list afterwards.

[Matthew Pickering]

The reason for removing the allow-newer on Cabal is this cabal thread. https://github.com/haskell/cabal/issues/7974

In short if you allow-newer on Cabal you can end up in situations where you choose a Cabal which requires a Cabal-syntax release, but can't easily specify this in a cabal file because of lack of support for conditionals in setup-depends.

[Ryan Scott]

can't easily specify this in a cabal file because of lack of support for conditionals in setup-depends

Wow, I had no idea that custom-setup stanzas don't support conditionals. That's a shame. In that case, we pretty much have no choice but to restrict the upper version bounds of Cabal for now. I still think it's worth documenting why we do this, since it's an exception to the usual treatment of GHC-bundled libraries.