New Cabal-syntax and an ancient Cabal conflict in a single package (e.g., old hackage-repo-tool on Hackage used both a new Cabal-syntax and ancient Cabal)

[Mikolaj]

One possible workaround is described here: https://hackage.haskell.org/package/Cabal-syntax-3.6.0.0

---

See github.com/haskell/hackage-security/runs/7814984300?check_suite_focus=true In hackage-security CI we once hit a bug:

tests/TestSuite/InMemRepo.hs:17:1: error:
    Ambiguous module name ‘Distribution.Text’:
      it was found in multiple packages:
      Cabal-3.6.0.0 Cabal-syntax-3.8.1.0

Edit: this was first spotted in cabal CI originally.

[Mikolaj]

hackage-repo-tool depends on hackage-security, which perhaps is compiled with old Cabal bundled with GHC, but then for some reason (no idea why; perhaps something unrelated fails in the build plan and the solver flips the Cabal-syntax flag and then indeed new Cabal-syntax is mandatory) a new Cabal-syntax is picked and hence the conflict.

[Mikolaj]

Actually, hackage-repo-tool on Hackage is ancient, so this may be why it's broken. Let me update on Hackage.

[ulysses4ever]

CI link in the OP doesn’t show me anything meaningful (eg no error).

[Mikolaj]

CI link in the OP doesn’t show me anything meaningful (eg no error).

The never-ending yellow CI job if full of errors. :)

[ulysses4ever]

Oh, right, I see that.

[Mikolaj]

hackage-repo-tool on Hackage is ancient, but it has reasonable bounds: Cabal (>=1.14 && <1.26 || >=2.0 && <2.6 || >=3.0 && <3.4) and up to date hackage-security bounds. How come this leads to a clash of Cabal-1.24.2.0 and Cabal-syntax-3.8.1.0? I'm worried that user packages may be similarly affected.

[Mikolaj]

I'm changing the topic, because hackage-repo-tool will be updated on Hackage as soon as I get the authorization, but the problem is more general --- our shrewd scheme of bounds on Cabal-syntax, etc., probably doesn't quite work.

[ulysses4ever]

For hackage-repo-tool specifically: somehow, hackage-security-0.6.2.2 gets dependent on Cabal-syntax-3.8.1.0, despite this dependency being hidden behind a flag (cf. cabal-plan tred output below). Curious...

[Mikolaj]

The solver is permitted to flip (some) flags. I'm not an expert on that, though. I think the manual field determines that. If it's not manual, it's solver-amenable. I think in this case it was the intention that solver would flip the flag if newer Cabal can be used. But we haven't imagined a situation like that, where due to other bounds, the solver can't use a new Cabal in some of the deps, while it can in others.