haskell.compiler.ghcjs: remove at 8.10.7

[sternenseemann]

• Add throwing alias if config.allowAliases.
• Flesh out changelog entry
• Remove ghcjs specific code from generic-builder.nix. I'd love to hear input on this. In theory, there is some value in keeping it, but I also don't see how we are going to correctly maintain this conditional code going forward. It also looks like it would make some things much simpler.

Closes #33768
Closes #44157
Closes #61710
Closes #167859
Closes #172802
Closes #340320

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

Remove ghcjs specific code from generic-builder.nix. I'd love to hear input on this. In theory, there is some value in keeping it, but I also don't see how we are going to correctly maintain this conditional code going forward. It also looks like it would make some things much simpler.

+many for removal. generic-builder is already complex enough and hard enough to maintain, every simplification is a big benefit. If somebody wants to keep using this, they will need to use an older nixpkgs instance with this still available - and then add the patches they need on top. It's just unrealistic to assume we can manage to keep this working without being able to test. We already see GHC on darwin regressing lately - and I'm sure this is related to not building it regularly in the haskell-updates hydra report anymore. There is no reason to assume it would work better for ghcjs.

[wolfgangwalther]

I think we can get rid of ghcCommand' here and just put "ghc" into ghcCommand directly.

There is one more usage of ghcCommand' further down, but I think this can eventually just be replaced with an uppercase "GHC" - makes little sense to keep this as another binding, I think.

[sternenseemann]

I don't really see the urgency inlining them everywhere, though.

[wolfgangwalther]

No urgency for sure, but less indirection is easier to read.

[wolfgangwalther]

Rebased to resolve merge conflicts.

[wolfgangwalther]

Diff LGTM. Also double checked any left-overs during rebase, didn't find any.

Changelog entry is there.

Do we need the alias and if so, only for haskell.compiler.ghcjs and/or haskell.packages.ghcjs or also for the versioned attributes? Seems like we have never added when dropping versions previously, so I'm inclined to not do it here either.

[sternenseemann]

May be worth it here since we're not just removing a version of GHC, but can be done separately.

Another questions is whether we want to do the removals on master (or staging if not possible) in order to get them into master faster and thus quicker feedback from downstream. We can always merge/cherry pick changes back to haskell-updates (or: into haskell-updates and cherry-pick onto quicker paths, maybe a even better option).

[maralorn]

I think an alias would be nice in this case.

Merging to master seems good to me. That will reach h-u in up to 48h won't it?

[wolfgangwalther]

Agree on merging into master; I'm open to do the same for most of the other drops (as long as they don't rebuild all of haskellPackages), to help #440271.

I have time and can work on rebasing this and the other branches + adding the alias here - but I don't want to interfere with your work @sternenseemann. Let me know where I can help.

[sternenseemann]

Feel free to rebase, I'm not doing anything on this branch right now.

All good now, thank you!

[wolfgangwalther]

Added the alias. The rebase was trivial with a single simple conflict to resolve. This should be good to go.

[trofi]

Bisect says that 60dfb9b haskell.compiler.ghcjs: remove at 8.10.7 broke the eval of haskell.packages.ghc902Binary.apply-refact in master as:

$ nix build --no-link -f. haskell.packages.ghc902Binary.apply-refact
error: attribute 'apply-refact_0_9_3_0' missing
   at pkgs/development/haskell-modules/configuration-ghc-9.0.x.nix:175:18:
      174|
      175|   apply-refact = self.apply-refact_0_9_3_0;
         |                  ^
      176|

Proposed possible change as:

• haskell.packages.ghc902Binary.apply-refact: fix the eval #441567