doc/using/overrides: Update for overlay style mkDerivation overrideAttrs

1 files changed, 6 insertions, 2 deletions

diff --git a/doc/using/overrides.chapter.md b/doc/using/overrides.chapter.md
index 66e5103531a..6e69423fe5f 100644
--- a/doc/using/overrides.chapter.md
+++ b/doc/using/overrides.chapter.md
@@ -39,14 +39,18 @@ The function `overrideAttrs` allows overriding the attribute set passed to a `st
 Example usage:
 
 ```nix
-helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
+helloWithDebug = pkgs.hello.overrideAttrs (finalAttrs: previousAttrs: {
   separateDebugInfo = true;
 });
 ```
 
 In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`, while all other attributes will be retained from the original `hello` package.
 
-The argument `oldAttrs` is conventionally used to refer to the attr set originally passed to `stdenv.mkDerivation`.
+The argument `previousAttrs` is conventionally used to refer to the attr set originally passed to `stdenv.mkDerivation`.
+
+The argument `finalAttrs` refers to the final attributes passed to `mkDerivation`, plus the `public` attribute which is the result of `mkDerivation` — the derivation or package.
+
+If only a one-argument function is written, the argument has the meaning of `previousAttrs`.
 
 ::: {.note}
 Note that `separateDebugInfo` is processed only by the `stdenv.mkDerivation` function, not the generated, raw Nix derivation. Thus, using `overrideDerivation` will not work in this case, as it overrides only the attributes of the final derivation. It is for this reason that `overrideAttrs` should be preferred in (almost) all cases to `overrideDerivation`, i.e. to allow using `stdenv.mkDerivation` to process input arguments, as well as the fact that it is easier to use (you can use the same attribute names you see in your Nix code, instead of the ones generated (e.g. `buildInputs` vs `nativeBuildInputs`), and it involves less typing).