`Cabal-3.8.1.0` depends on too recent `process-1.6.14`, rendering it unusable with package `ghc-9.2.4` and older

[andreasabel]

Lifted from #8489 (comment):

Cabal-3.8.1.0 comes with a constraint process >= 1.6.14 (released 2022) for ghc >= 8.2 (released 2017!). This looks non-sensical to me. It makes cabal trying to reinstall the ghc package, which is bound to fail. In the wild:

• Build with Cabal-3.8 and GHC 9.4 hackage-server#1141 (comment)

cabal-3.6.2.0: Could not resolve dependencies:
[__0] trying: hackage-server-0.5.1 (user goal)
[__1] rejecting: hackage-server:!test (constraint from config file, command line flag, or user target requires opposite flag selection)
[__1] trying: hackage-server:*test
[__2] trying: doctest-parallel-0.2.5 (dependency of hackage-server *test)
[__3] trying: ghc-9.2.4/installed-9.2.4 (dependency of doctest-parallel)
[__4] next goal: Cabal (dependency of hackage-server)
[__4] rejecting: Cabal-3.6.3.0/installed-3.6.3.0 (conflict: hackage-server => Cabal^>=3.8.1.0)
[__4] rejecting: Cabal-3.8.1.0 (conflict: ghc => process==1.6.13.2/installed-1.6.13.2, Cabal => process>=1.6.14.0 && <1.7)

Blame for the process >= 1.6.14 constraint goes to 95cf762. (Ping @robx.)

Sat Jul 9 14:48:25 2022 +0200
Cabal: depend on process-1.6.14.0 to fix waitForProcess error message

This is guarded to be for GHC from 8.2 only, since the process release depends on base-4.10.

This extra constraint seems to have been removed from master in the meantime.

However, it seems like a release of Cabal-3.8 is warranted to render Cabal-3.8 usable with the preinstalled ghc package below 9.4.

[andreasabel]

Reproducer: cabal build -w 9.2.4 on a .cabal with these dependencies:

    build-depends:
        base
      , Cabal == 3.8.1.0
      , ghc

This gives:

Build profile: -w ghc-9.2.4 -O1
In order, the following will be built (use -v for more details):
 - process-1.6.16.0 (lib:process) (requires download & build)
 - ghc-9.2.4 (lib) (requires build)
 - Cabal-3.8.1.0 (lib) (requires build)
...

I attach the toy project as zip file.
issue-8554.zip

[Mikolaj]

@andreasabel: I can't see this bound on https://hackage.haskell.org/package/Cabal nor on master nor 3.8 branch in the repo.

And your log says "cabal-3.6.2.0: Could not resolve dependencies".

Could you investigate some more?

[ulysses4ever]

Cabal has backwards compatibility obligation w.r.t. GHC the program, which it adheres.I don't know of any promises w.r.t. ghc the package.

[ulysses4ever]

Sorry, wrong button and premature send.

So, as it stands, a dependency (if it exists) or constraint that rules out older ghcs doesn't violate anything per se. Maybe we should consider introducing a back-compat promise for ghc (the package)? It may sound reasonable but is it worth it? Beneficiaries of this would be those who depend on both Cabal and ghc. Not a big market, I'd guess. Of course, if there are critical infrastructure packages among those, it may be justified.

[Mikolaj]

Actually, I can see the bound for process on Hackage when I look inside the .cabal file --- Hackage doesn't display the bound on the main page, because of the condition. I'm still puzzled where this bound has been removed on 3.8 branch. Blame shows nothing.

[Mikolaj]

OK, I've found it: #8342

So, it seems this is fixed already, just not released. Apologies for any inconvenience.