haskellPackages.callHackage: updating all-cabal-hashes do not invalidate callHackage

Packages built with `haskellPackages.callHackage` won't be rebuilt when
updating `all-cabal-hashes`.

The removed comment was keeping a reference to the `cabal2nix` call,
which itself depends on `all-cabal-hashes`, in order to keep this file
during a garbage collection.

The tradeoff is between:

- The current behavior: a mass rebuild, any change of `all-cabal-hashes`
  triggers a rebuild of all the packages built with `callHackage` and
  packages which depend on them. This can take hours, and may happen
  after a "small" unrelated change (i.e. an user is bumping
  `all-cabal-hashes` in order to use a new package from hackage). It
  also have global impacts in a project (long rebuild in CI, new entries
  in cache, developers need to fetch the new entries, ...). In this
  context, `cabal2nix` entries are not garbage collected.
- The new behavior: No mass rebuild, but `cabal2nix` derivations need to
  be recomputed after a garbage collection. This is usually fast (a few
  seconds by call), linear with the number of calls and should not
  happen a lot (i.e. users are not garbage collecting everyday).

See https://github.com/NixOS/nixpkgs/issues/194751 for details.

nixos/doc/manual/from_md/release-notes/rl-2211.section.xml

@@ -1694,6 +1694,22 @@ services.github-runner.serviceOverrides.SupplementaryGroups = [
           <literal>picom</literal> to quit instead.
         </para>
       </listitem>
+      <listitem>
+        <para>
+          <literal>haskellPackage.callHackage</literal> is not always
+          invalidated if <literal>all-cabal-hashes</literal> changes,
+          leading to less rebuilds of haskell dependencies.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          <literal>haskellPackages.callHackage</literal> and
+          <literal>haskellPackages.callCabal2nix</literal> (and related
+          functions) no longer keep a reference to the
+          <literal>cabal2nix</literal> call used to generate them. As a
+          result, they will be garbage collected more often.
+        </para>
+      </listitem>
     </itemizedlist>
   </section>
 </section>

nixos/doc/manual/release-notes/rl-2211.section.md

@@ -529,4 +529,8 @@ Available as [services.patroni](options.html#opt-services.patroni.enable).
 
 - The option `services.picom.experimentalBackends` was removed since it is now the default and the option will cause `picom` to quit instead.
 
+- `haskellPackage.callHackage` is not always invalidated if `all-cabal-hashes` changes, leading to less rebuilds of haskell dependencies.
+
+- `haskellPackages.callHackage` and `haskellPackages.callCabal2nix` (and related functions) no longer keep a reference to the `cabal2nix` call used to generate them. As a result, they will be garbage collected more often.
+
 <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->

pkgs/development/haskell-modules/make-package-set.nix

@@ -161,17 +161,13 @@ let
     src    = "${component}/${name}.cabal";
   };
 
-  # Adds a nix file as an input to the haskell derivation it
-  # produces. This is useful for callHackage / callCabal2nix to
-  # prevent the generated default.nix from being garbage collected
-  # (requiring it to be frequently rebuilt), which can be an
-  # annoyance.
+  # Adds a nix file derived from cabal2nix in the passthru of the derivation it
+  # produces. This is useful to debug callHackage / callCabal2nix by looking at
+  # the content of the nix file pointed by `cabal2nixDeriver`.
+  # However, it does not keep a reference to that file, which may be garbage
+  # collected, which may be an annoyance.
   callPackageKeepDeriver = src: args:
     overrideCabal (orig: {
-      preConfigure = ''
-        # Generated from ${src}
-        ${orig.preConfigure or ""}
-      '';
       passthru = orig.passthru or {} // {
         # When using callCabal2nix or callHackage, it is often useful
         # to debug a failure by inspecting the Nix expression