关于Nixpkgs中Fixed Point用于包覆盖的技术问询

1. 解释“覆盖集合中的属性以使其被依赖属性递归选取”的含义，并结合示例说明 #

这句话指的是在Nixpkgs的覆盖机制中，当你替换包集合里的某个属性（比如某个包的定义）时，所有依赖该属性的其他包会自动使用这个新的属性值，而非原始值，这种依赖传递是递归发生的。

举个类似17.3.1的示例：假设我们要修改graphviz的构建参数，同时让依赖它的asciidoc-full自动使用这个修改后的版本：

let
  pkgs = import <nixpkgs> {
    config = {
      packageOverrides = origPkgs: {
        # 覆盖graphviz属性，修改其构建选项
        graphviz = origPkgs.graphviz.override {
          enableX11 = false;
        };
      };
    };
  };
in pkgs.asciidoc-full

这里asciidoc-full的定义中依赖pkgs.graphviz作为输入工具。当我们覆盖graphviz后，asciidoc-full在构建时会递归选取这个新的graphviz版本——不仅是直接依赖，任何间接依赖graphviz的包（比如asciidoc-full依赖的其他工具如果也用graphviz），都会自动使用覆盖后的版本。

2. 解释“nixpkgs返回包集合的不动点（Fixed Point）”的含义 #

不动点属于函数概念，包集合为何是函数？ #

Nixpkgs的顶层结构本质是一个函数：它接受一个包含自身的参数（通常命名为pkgs），输出完整的包集合。这样设计是因为Nix包之间存在大量互相依赖，比如包A需要引用包B，包B可能又依赖包C，而这些依赖都是通过pkgs.xxx的形式引用集合内的其他包。把包集合设计成函数，才能实现这种自引用的依赖关系。

nixpkgs为何返回不动点？它是否与示例类似？ #

不动点的核心是满足f(x) = x，对于Nixpkgs来说，这个函数就是“输入一个包集合的雏形，输出完整的、包含所有依赖的包集合”。返回不动点的原因是解决包之间的循环依赖和自引用问题：只有当函数的输出等于输入时，所有包的依赖才能指向集合内的正确版本，形成一个自洽的完整集合。

它和let newpkgs = pkgs (newpkgs // overrides); in newpkgs示例完全类似——这个示例就是手动构造不动点的过程：newpkgs是函数pkgs应用到newpkgs加上自定义覆盖后的结果，最终newpkgs会收敛到一个稳定值，满足newpkgs = pkgs(newpkgs // overrides)，这和Nixpkgs内部处理覆盖、生成最终包集合的逻辑一致。

3. 解释“packageOverrides用于注入覆盖配置”的含义 #

packageOverrides是Nixpkgs提供的一个配置入口，本质是一个函数：它接受原始的未修改包集合作为参数，返回一个包含自定义修改的属性集合。通过这个函数，你可以：

• 替换现有包的定义（比如修改版本、构建参数）
• 添加自定义的新包
• 删除或屏蔽某些包

它的作用是让用户无需修改Nixpkgs源码，就能自定义包集合的内容，并且这些修改会自动递归应用到所有依赖该属性的包上，最终整合到不动点生成的最终包集合中。

4. 为何“此时pkgs.asciidoc-full是包含graphviz输入的派生项”？ #

因为asciidoc-full的构建定义中，明确将pkgs.graphviz列为buildInputs（或类似输入依赖）。当你通过packageOverrides覆盖了graphviz的属性后，pkgs.asciidoc-full在生成派生项（derivation）时，会引用这个新的graphviz版本作为输入。

Nix的派生项是纯函数式的，输入依赖的任何变化都会导致派生项的哈希和内容更新，所以此时的pkgs.asciidoc-full派生项会包含覆盖后的graphviz作为输入组件。

5. 为何“新构建的asciidoc将依赖新的graphviz，而旧的asciidoc不受影响仍使用旧graphviz”？ #

这是由Nix的纯函数式特性和内容寻址存储决定的：

• 旧的asciidoc派生项是基于原始graphviz的输入和构建参数生成的，它的存储路径和哈希值是固定的，不会因为新graphviz的存在而改变。
• 新的asciidoc是基于覆盖后的graphviz生成的，会生成一个全新的派生项，拥有独立的存储路径和哈希。

两者在Nix的存储中是完全独立的实体，不会互相干扰——用户可以同时保留和使用新旧两个版本，旧版本的依赖链不会被新版本修改。

内容的提问来源于stack exchange，提问作者Tim