brandon s allbery kf8nh

I should also note that we don't (and in general can't, without a reorganization of our CI) validate _older_ versions of cabal-install. In particular, `validate` is pretty brittle. IIRC 3.10.x...

I think this is just a vagary in how versions are compared: the actual constraint has to be `--constraint hashable==1.5.0.0`. Sorry for the abbreviation.

The complaint is that your ghc (9.10.2) is too new: `tasty-bench` won't build with the `ghc-prim` that ships with it. Try it with 9.8.

That failure is due to git not allowing `file` transport by default any more for security reasons. There's a ticket for it but I'm busy today and don't have time...

I believe the supported way to do this is not to use cabal at all, but the `Setup.hs` interface. However, what you're asking for will still be made difficult by...

Is that really true? Most distros tend to prefer to package dependencies their way instead of vendoring, from what I've seen.

I've been thinking it would be nice of the libdir contained a file of bootlibs and dependencies, which would allow us to both get the non-reinstallable libs and treat the...

Also, do we need to worry about the likes of `ghc-internal`? -- ETA: wrong one, I saw several new internal libs in the list. `ghc-boot`, `ghc-boot-th`, `ghc-experimental`.

"The build plan contains `ghc`" is exactly the case I want to capture. I think I missed a case, though: `Just []` captures things like `text` which are reinstallable.

The second would matter _if_ the bootlibs started to include a package with a partial or disjoint set of dependencies; I was thinking in terms of forward compatibility.