Looking for a parsec maintainer to assist with GHC 9.14 compatibility (is this package still actively maintained?)

1

I’m looking for an active maintainer for parsec to help with a GHC 9.14.1 compatibility issue. Specifically, I’m hoping someone would be willing to:

Context: The parsec package currently has an outdated base upper bound (< 4.22) on Hackage.

Even though the parsec-3.1.18.0 boot package bundled with GHC 9.14.1 was itself compiled against base-4.22.0.0, the version on Hackage (with an outdated upper bound on base) seems to cause dependency resolution failures for packages that transitively depend on parsec-3.1.18.0 when building with GHC 9.14.1.

One workaround for affected packages is --allow-newer=parsec:base, but it would be great for downstream packages to be able to support GHC 9.14.1 without requiring this override.

I believe this issue has been known about since at least June 2025, and was raised again in January 2026 (haskell/parsec/197), but so far we’ve been unsuccessful at attracting a maintainer’s attention, hence this message.

Any help would be greatly appreciated. Many thanks for reading!

Two concrete examples of affected packages:

2 Likes
2

As a temporary measure, a Hackage trustee should be able to edit the Cabal metadata to fix GHC 9.14 building. I don’t recall how to get in touch with them, though-- there should be plenty on this Discourse, or you could try emailing hackage-admin@haskell.org .

1 Like
3

I believe the preferred way to contact the Hackage trustees is to open an issue on their GitHub repo: Issues · haskell-infra/hackage-trustees · GitHub

4 Likes
4

Many thanks for your help with this @jaror, @raehik.

I’ve raised an issue on the Hackage trustees GitHub repo here:

2 Likes
5

This looks like an error in the GHC release process.

@wz1000 bumped this in the GHC submodules.

I don’t know if there was any communication with the parsec maintainers, but GHC shipping with unreleased boot libs has been a recurring issue.

3 Likes
6

Thanks for the pointer @hasufell.

It does seem that GHC’s GitLab mirror of parsec has the following two commits:

AFAICT neither of these branches (or commits) exists in the canonical repository on GitHub as referenced by the Hackage package description.

It seems like the process expects these changes to be propagated back at release time, and that this step was missed for GHC 9.14.1. Is that right?

If so, perhaps this part of the process could be revised? The repository is described as a “mirror”, but GHC-specific commits are being made directly to it, creating two diverging sources of truth. The ghc-10.0 branch suggests the same issue is lined up to recur with GHC 10.0. :upside_down_face:

I wonder if it’s feasible to instead propagate changes in the following order:

  1. First, to the canonical source repository (currently on GitHub);
  2. then to Hackage;
  3. and finally to the GHC GitLab mirror.

Or alternatively, perhaps the GitLab version could be blessed as the source of truth (reflected in the Hackage package description), and the GitHub version treated as a mirror?

(I appreciate there may be constraints I’m not aware of, and I’d be curious to hear from anyone who knows more about how this process works in practice.)

1 Like
7

No, it seems a GHC maintainer (@bgamari) opened a PR against the parsec repository well in advance of the 9.14.1 release: Bump base upper bound to <4.23 by bgamari · Pull Request #193 · haskell/parsec · GitHub

I don’t know why this wasn’t merged, but unfortunately since parsec is a boot library and its constraints need to be consistent with the version of base released with GHC, the GHC maintainers wouldn’t have had another option but to distribute GHC with a patched parsec. In this case the immediate fix is to revise the package bounds, but it does seem like a new maintainer for parsec might be appropriate.

1 Like
8

You have at least two options:

  1. Not bump parsec
  2. Contact hackage trustees to do a revision prior to the GHC release

Shipping it anyway and hoping for the best is not good procedure.

2 Likes