[3.6] allow HTTP-4000.4, hashable-1.4, time-1.11

[juhp]

This may allow cabal-install-3.6 to build with Stackage Nightly

[Mikolaj]

3.6 CI (and possibly the test suite as well) was not firefighted enough to keep it alive, for a long time, so this won't pass. Is a Hackage revision required? Have you run tests manually? What failures did you get?

[andreasabel]

I can confirm that with this patch and a base bump, cabal-install-3.6.2.0 builds successfully with current stackage nightly (nightly-2022-08-30).

I fails to build using cabal because of

• 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) #8370

But this is independent of this patch, just a fresh copy of cabal-install-3.6.2.0 suffers the same problem:

cabal-install-3.6.2.0$ cabal build -w ghc-8.10.7
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
 - Cabal-3.6.3.0 (lib) (requires build)
 - Cabal-syntax-3.8.1.0 (lib) (requires build)
 - ...

We know how this ends:

[127 of 178] Compiling Distribution.Client.FetchUtils ( src/Distribution/Client/FetchUtils.hs, /Users/abel/tmp/tmp/cabal-install-3.6.2.0/dist-newstyle/build/x86_64-osx/ghc-8.10.7/cabal-install-3.6.2.0/x/cabal/build/cabal/cabal-tmp/Distribution/Client/FetchUtils.o )

src/Distribution/Client/FetchUtils.hs:195:36: error:
    • Couldn't match type ‘Distribution.Types.PackageId.PackageIdentifier’
                     with ‘Cabal-syntax-3.8.1.0:Distribution.Types.PackageId.PackageIdentifier’

Anyhow, revising cabal-install-3.6.2.0 to build with nightly-2022-08-30 (GHC 9.2.4) seems reasonable.
Should I go ahead an push the button?

[andreasabel]

(P)review of the revision:

$ hackage-cli push-cabal --incr-rev *.cabal
Pushing "cabal-install.cabal" (cabal-install-3.6.2.0~1) [review-mode] ...

Changes:

• Changed the executable 'cabal' component's library dependency on 'HTTP'
  from >=4000.1.5 && <4000.4
  to >=4000.1.5 && <4000.5

• Changed the executable 'cabal' component's library dependency on 'base'
  from >=4.8 && <4.15
  to >=4.8 && <4.17

• Changed the executable 'cabal' component's library dependency on 'hashable'
  from >=1.0 && <1.4
  to >=1.0 && <1.5

• Changed the executable 'cabal' component's library dependency on 'time'
  from >=1.5.0.1 && <1.11
  to >=1.5.0.1 && <1.12

[juhp]

(I was thinking if an upperbound for hackage-security would help avoid the Cabal-syntax issue, but I agree with you completely that it would be great to be able to get cabal-install to build in current Stackage Nightly with these changes 👍)

[Mikolaj]

Yes, if there is no better solution, let's move through with these Hackage revisions. We can't see how they'd make things any worse. To make sure, we could check out the 3.6.2 tag, apply the patch, run cabal-testsuite and see how many tests fail (if many more than in last 3.6.2 CI, something may be amiss).

I was thinking if an upperbound for hackage-security would help avoid the Cabal-syntax issue

Could you elaborate?

[Mikolaj]

how many tests fail

Actually, fail or are skipped, because often a bounds-related breakage manifests via not building tools, which leads to tests being skipped.

[juhp]

I was thinking if an upperbound for hackage-security would help avoid the Cabal-syntax issue

Could you elaborate?

I mean that hackage-security-0.6.1.0 looks more compatible with cabal-install-3.6. :)

See Andreas' comment above and similarly mine

[Mikolaj]

I mean that hackage-security-0.6.1.0 looks more compatible with cabal-install-3.6. :)

Oh, I see, hackage-security bound could be changed to <= 0.6.1.0 as a cabal-install-3.6.2 revision on Hackage? Yes, it's quite possible it would help. @andreasabel, what do you think? If we go for it, this PR should be updated, too, so that the branch and the revision on Hackage are in sync regarding bounds.

[juhp]

Well the hackage-security issue could also be handled in a separate PR perhaps since it is really orthogonal to the bounds here.

But I see now that that Stackage can build cabal-install-3.6 with hackage-security-0.6.2, since both lts-19 and current nightly have Cabal-syntax-3.6. So just restricting hackage-security to <0.6.2 would actually break current Stackage... therefore it is not ideal either. I think there is no way to specify hackage-security to <0.6.2 || (hackage-security to <0.7 && Cabal-syntax < 3.8) or is there?

[andreasabel]

@juhp wrote:

I think there is no way to specify hackage-security to <0.6.2 || (hackage-security to <0.7 && Cabal-syntax < 3.8) or is there?

Not directly, but maybe using flags. (Yet flags are handled slightly different in stack and cabal.)

But fixing the Cabal-syntax issue is orthogonal to making the revisions to build cabal-install-3.6 in nightly, it seems, so maybe this discussion should be done in a new issue?

To make sure, we could check out the 3.6.2 tag, apply the patch, run cabal-testsuite

Of course, the testsuite might require more patches to run.

(I'll be unavailable for the next three weeks, and don't have the time for doing this experiment in the near future.)

[Mikolaj]

All right. I propose we make the revisions @andreasabel lists and be done with this ticket. At least one problem solved.

[andreasabel]

Ok, I hit the button: https://hackage.haskell.org/package/cabal-install-3.6.2.0/revisions/

[Mikolaj]

Thank you. Let's merge.