Dependency bounds on Hackage are wrong?

[chris-martin]

Question or bug report, I'm not sure which. On Hackage, stm-2.5.0.0 has the bound base (>=4.3 && <4.14). But I'm using the stm package in a project that builds with base-4.15. How does this work? Is it because there is a more up-to-date version of stm bundled with GHC? Can/should Hackage be updated to reflect the latest knowledge?

[Fuuzetsu]

If you're using base-4.15 that probably means you're using the unreleased 9.0.x version of GHC which has the stm (and other libraries) dependency versions bumped. This is common practice in the GHC tree. Once the release is ready, I believe that's when the new dependency versions get updated in packages and/or Hackage.

So probably there should be nothing done right now. base-4.15 is not even a thing on Hackage yet either.

If the version bounds are causing you issues, I think you should probably be using a released GHC version.

[chris-martin]

If you're using base-4.15

Why isn't there even an stm on Hackage that supports base-4.14, though?

the unreleased 9.0.x version of GHC

It isn't released? The GHC blog says it's released.

[Fuuzetsu]

Hm, hm, you're right. I even see it on https://www.haskell.org/ghc/download.html ; I don't know what happened, I think I was tripping or something.

I guess you must be right then.

[shana@aya:~/programming/ghc]$ git branch
* (HEAD detached at ghc-9.0.1-release)
  bitwise-constant-folding
  ghc-8.6.4-rwcs
  master

[shana@aya:~/programming/ghc]$ cat libraries/stm/stm.cabal | grep base
        base  >= 4.3 && < 4.16,

I guess stm bounds should be bumped. I suspect no-one complained before because stm and base both come with GHC so the bounds between on Hackage probably don't really matter?

[chris-martin]

Yeah, what's on Hackage in some sense doesn't matter, I just figure it's important to have correct documentation. Presumably that information is printed there for people to read it.

[sloane-shark]

Interestingly, I think this is biting me when using the relude package... relude depends on stm directly, which I guess triggers cabal's constraint solver, and results in this error:

Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: rep-0.1.0.0 (user goal)
[__1] trying: relude-1.0.0.1 (dependency of rep)
[__2] trying: stm-2.5.0.0 (dependency of relude)
[__3] next goal: base (dependency of rep)
[__3] rejecting: base-4.14.1.0/installed-4.14.1.0 (conflict: stm => base>=4.3
&& <4.14)
[__3] skipping: base-4.15.0.0, base-4.14.1.0, base-4.14.0.0 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '>=4.3 && <4.14' from 'stm')
[__3] rejecting: base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, base-4.11.0.0,
base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0,
base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0,
base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0,
base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1,
base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1
(constraint from non-upgradeable package requires installed instance)
[__3] fail (backjumping, conflict set: base, rep, stm)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, stm, relude, rep

I am using cabal build --allow-newer to sidestep the issue.

[mode89]

Same here. Building with ghcjs-8.10.4:

based on GHC version 8.10.4
Warning: don't know how to find change monitoring files for the installed
package databases for ghcjs
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: criterion-1.5.9.0 (user goal)
[__1] trying: exceptions-0.10.4 (dependency of criterion)
[__2] trying: stm-2.5.0.0 (dependency of exceptions)
[__3] next goal: base (dependency of criterion)
[__3] rejecting: base-4.14.1.0/installed-6zK9hwRU1FG2kosw1Xpoun (conflict: stm
=> base>=4.3 && <4.14)
[__3] skipping: base-4.15.0.0, base-4.14.1.0, base-4.14.0.0 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '>=4.3 && <4.14' from 'stm')
[__3] rejecting: base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, base-4.11.0.0,
base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0,
base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0,
base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0,
base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1,
base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1
(constraint from non-upgradeable package requires installed instance)
[__3] fail (backjumping, conflict set: base, criterion, stm)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, stm, criterion, exceptions
Try running with --minimize-conflict-set to improve the error message.

[sjakobi]

GHC 8.10.4 includes stm at faf9904. GHC 9.0.1 includes 444f672. In both cases the library code is not the one released as v2.5.0.0, because they include 3860cd1.

In fact the GHC release tracking tickets for GHC >= 8.10.2 list the stm release as TODO, e.g. https://gitlab.haskell.org/ghc/ghc/-/issues/18518, https://gitlab.haskell.org/ghc/ghc/-/issues/18216.

[sjakobi]

Apparently GHC 8.10.5 will include the new stm-2.5.0.1 release: https://gitlab.haskell.org/ghc/ghc/-/issues/19859

Can this issue be closed now?

[kquick]

It would be nice to have the hackage version updated: some distros won't ship 8.10.5 for a while, so having an stm indicating compatibility with >= 8.10 && < 8.10.5 would be good, even for posterity, otherwise those GHC versions will always be a black hole.