Tracking Issue: Removing GHC 8.10

[maralorn]

It is not yet clear, when we can or want to drop GHC 8.10, but there is the intention to do this if possible and the following things currently depend on GHC 8.10 and thus need to be dealt with first:

• Last ghc version for which there exists the old ghcjs is 8.10 (maintainer: obsidian systems) haskell.compiler.ghcjs: remove at 8.10.7 #422342
• Some elm packages still need 8.10 (maintainer: @turboMaCk )
  • elmi-to-json elmPackages.elm-coverage: drop #415911
  • elm-instrument elmPackages.elm-instrument: build using GHC 9.4 #413234
• pakcs (maintainer: @t4ccer)
• yi (no maintainers)
• hasura-graphql-engine (maintainer: @Lassulus) (broken anyways)

GHC 8.10.7 (binary) is also used for bootstrapping other GHC versions:

• As boot compiler for GHC 9.0.2 haskell.compiler.ghc902: remove at 9.0.2 #381265
• As boot compiler for GHC 9.2.* (could be replaced by GHC 9.0.2)
• As boot compiler for GHC 9.4.* (could be replaced by GHC 9.0.2, but not 9.2.*) haskell.compiler.ghc902Binary: init at 9.0.2 #411397

That GHC 9.4 depends on 8.10.7 for bootstrapping is troublesome because:

• It is the latest GHC to support TemplateHaskell in pkgsStatic: Build failure: haskell.compiler.ghc{8107,902,92*,94*} on *-darwin #367686
• It is the latest GHC we can cross-compile which is interesting for bootstrapping a native GHC in the future (e.g. on riscv64-linux).

[t4ccer]

Moving pakcs is non-trivial because it doesn't build on mtl 2.3 even after bumping to 3.7.2. I'll try patching it later as it usually boils down to adding imports for reexports removed in mtl 2.3

[emilazy]

Copying what I said on Matrix: elm-instrument and elm-format build on GHC 9.4 without modifications, and so pose no barrier to GHC 8.10 removal. (They would build with what looks like trivial import fixes on 9.6, too.)

elmi-to-json has dependencies that are broken on a newer GHC version, but there’s already an upstream issue about known vulnerabilities in some of its dependencies, so we probably shouldn’t be shipping it in its present state anyway (at least without knownVulnerabilities). I think it would be okay to expect someone to patch it for newer GHC versions and non‐vulnerable libraries or else remove it.

[turboMaCk]

elmi-to-json is library that is used by some nodejs dependecies, it's not useful by itself. We need to check which other packages would removal break. The known vulnerabilities are not that big deal because they do not have impact on security of elmi-to-json itself.

[emilazy]

If the package is important we could patch it to use libraries that work with the newer GHC (and send a PR as it seems the author would like help fixing such issues).

[turboMaCk]

I think it might not be that important anymore. I have a feeling that some downstream deps might even already moved away from using it. We need to check. In any case the package itself is not useful so we definitely should consider removing it if it doesn't break too much stuff. Otherwise I would provide patch upstream we can apply - in past I already provided some and upstream was fast to accept them.

[sternenseemann]

A more low hanging fruit in terms of GHC removals is probably GHC 9.0.2. I'm confident we could immediately remove it and we probably should do so immediately after the 24.11 release.

Edit: #381265

[sternenseemann]

https://mail.haskell.org/pipermail/libraries/2024-October/031677.html

[sternenseemann]

In the past two years, people have occasionally opened issues about ghcjs regressions (these happen inevitably because we can't test the full ghcjs on Hydra due to its close 4GB output size).

• Build failure: ghcjs #260271
• Build failure: haskell.compiler.ghcjs #376582

However, I haven't really been able to turn up any active projects that would suffer significantly. The Reflex/whatever it's called ecosystem heavily pins nixpkgs (maybe beyond what is reasonable), but it is also prevalent in other users, probably since ghcjs has to be manually compiled (e.g. dhall-lang.org, miso, …). On balance, it seems justifiable to drop it, especially since the JS backend for GHC keeps improving (as does our support for it) and we don't really have active maintainers for it on the nixpkgs side.

I'm not sure if we should maybe do a last call on Discourse?

[maralorn]

@sternenseemann That would be part of the deprecation policy I proposed. I can update and post it to discourse if you want. https://md.darmstadt.ccc.de/FZwe_M9GQwWVnYfO0U4qJA#

[maralorn]

Ah, well, there is a problem. I don’t think we announced deprecation in the 24.11 changelog, did we? Then maybe we shouldn’t announce the policy because we don’t intend to conform to it?

[alyssais]

25.05 is coming up — just mentioning in case anything is intended for that changelog :)