haskellPackages: add script to sweep for unused overrides

[alexfmpe]

Used for #384127 , #384431, #397255

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (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.

---

Add a 👍 reaction to pull requests you find important.

[maralorn]

Fancy, I assume you use something like this regularly?

I guess the worst this can do is bit-rot. So I am in favor.

[alexfmpe]

Fancy, I assume you use something like this regularly?

Well it's a much better approach than my old "let's look at old enough overrides and see if they can be cleaned up".

I also just recently realised this could probably be re-purposed for doCheck on non-haskell packages

[alexfmpe]

Re-worked this so it's much more versatile. It's not particularly haskellPackages specific anymore, so maybe it can be placed elsewhere?

[alexfmpe]

cc @wolfgangwalther

[maralorn]

I feel it is good here. Why do you use overrideAttrs for doCheck and patches? We normally also control these via overrideCabal within nixpkgs.

[alexfmpe]

Why do you use overrideAttrs for doCheck and patches? We normally also control these via overrideCabal within nixpkgs.

I had overrideCabal at start then noticed that doCheck and patches being arguments to mkDerivation meant the mechanism could also be used for derivations that aren't cabal packages

[sternenseemann]

Arguably, here the better approach is to build srcOnly pkg and see whether it fails which is much cheaper.