CI doesn't test installation from Hackage

[geekosaur]

Describe the bug
See #9833.

Neither standard nor release CI tests building from Hackage; both always use the Cabal and Cabal-syntax in our tree, via packages: lines in their respective cabal.project files. You have to build from Hackage using a ghc that ships with Cabal 3.10.x to get a failure: older versions will fail the ^>= 3.10 version constraint, and the solver will then prefer the newest version and the build will succeed.

[geekosaur]

Seems like the correct course of action is to capture the sdists from a build as artifacts and generate a local no-index repo from them, then do a build without a cabal.project so the in-tree versions aren't used and we are simulating a standard build from Hackage.

[Mikolaj]

Yes, sounds plausible. If we just do --dry-run builds, it's very cheap, so we can try many variants. Perhaps pick one of them and run with tests as well.

[geekosaur]

#6955 claims that releases are done from sdists, but in fact they're done from a clone of this repo on Gitlab. I think that's necessary, since they need to be done with cabal.release.project.

[geekosaur]

@ulysses4ever didn't understand the problem from the above description, so I'll try to expand upon it.

cabal-install-3.10.3.0 initially had Cabal ^>= 3.10 in its build-depends (https://hackage.haskell.org/package/cabal-install-3.10.3.0/revision/0.cabal). If the ghc used to run cabal install cabal-install has Cabal 3.10.* as a bootlib, the solver prefers it and the build fails because cabal-install uses an API that isn't present in Cabal versions below 3.10.3.0. (I am not clear on whether this constitutes a PVP violation, as there are Cabal APIs that are intended for consumption by, and possibly only usable by, cabal-install.)

ghcs that include a Cabal bootlib which isn't 3.10.* are not affected, as it doesn't match the build-depends and so the solver picks the latest Cabal version that does, which means 3.10.3.0 is used.

Some ramifications of this are:

• there's no point in running this check on master, as a development version will never be a ghc bootlib
• it only needs to be run on the most recent ghc release, but unless we introduce specific requirements on the matrix.ghc entry in .github/workflows/validate.yml (ordered in reverse, except that ghc prereleases like we used for 3.12.0.0 must not come first) this is difficult. At present I plan to inherit matrix.ghc from the main validate run.

[geekosaur]

FTR, it's been decided that that change should not have been backported, so I am revising my WIP (not yet a PR) to fail if it happens again.