nixos: use only URI fragment in manual options links
This commit is contained in:
parent
800c1f15a3
commit
ef37170c6d
4 changed files with 18 additions and 20 deletions
|
@ -30,7 +30,7 @@ enable the Apache HTTP Server with `/webroot` as the document root.
|
|||
|
||||
Sets can be nested, and in fact dots in option names are shorthand for
|
||||
defining a set containing another set. For instance,
|
||||
[`services.httpd.enable`](options.html#opt-services.httpd.enable) defines a set named
|
||||
[](#opt-services.httpd.enable) defines a set named
|
||||
`services` that contains a set named `httpd`, which in turn contains an
|
||||
option definition named `enable` with value `true`. This means that the
|
||||
example above can also be written as:
|
||||
|
|
|
@ -34,9 +34,9 @@ Here, we include two modules from the same directory, `vpn.nix` and
|
|||
```
|
||||
|
||||
Note that both `configuration.nix` and `kde.nix` define the option
|
||||
[`environment.systemPackages`](options.html#opt-environment.systemPackages). When multiple modules define an
|
||||
[](#opt-environment.systemPackages). When multiple modules define an
|
||||
option, NixOS will try to *merge* the definitions. In the case of
|
||||
[`environment.systemPackages`](options.html#opt-environment.systemPackages), that's easy: the lists of
|
||||
[](#opt-environment.systemPackages), that's easy: the lists of
|
||||
packages can simply be concatenated. The value in `configuration.nix` is
|
||||
merged last, so for list-type options, it will appear at the end of the
|
||||
merged list. If you want it to appear first, you can use `mkBefore`:
|
||||
|
@ -49,7 +49,7 @@ This causes the `kvm-intel` kernel module to be loaded before any other
|
|||
kernel modules.
|
||||
|
||||
For other types of options, a merge may not be possible. For instance,
|
||||
if two modules define [`services.httpd.adminAddr`](options.html#opt-services.httpd.adminAddr),
|
||||
if two modules define [](#opt-services.httpd.adminAddr),
|
||||
`nixos-rebuild` will give an error:
|
||||
|
||||
```plain
|
||||
|
@ -68,8 +68,8 @@ defined in other modules. This is what the `config` function argument is
|
|||
for: it contains the complete, merged system configuration. That is,
|
||||
`config` is the result of combining the configurations returned by every
|
||||
module [^1] . For example, here is a module that adds some packages to
|
||||
[`environment.systemPackages`](options.html#opt-environment.systemPackages) only if
|
||||
[`services.xserver.enable`](options.html#opt-services.xserver.enable) is set to `true` somewhere else:
|
||||
[](#opt-environment.systemPackages) only if
|
||||
[](#opt-services.xserver.enable) is set to `true` somewhere else:
|
||||
|
||||
```nix
|
||||
{ config, pkgs, ... }:
|
||||
|
|
|
@ -37,9 +37,9 @@
|
|||
<para>
|
||||
Sets can be nested, and in fact dots in option names are shorthand
|
||||
for defining a set containing another set. For instance,
|
||||
<link xlink:href="options.html#opt-services.httpd.enable"><literal>services.httpd.enable</literal></link>
|
||||
defines a set named <literal>services</literal> that contains a set
|
||||
named <literal>httpd</literal>, which in turn contains an option
|
||||
<xref linkend="opt-services.httpd.enable" /> defines a set named
|
||||
<literal>services</literal> that contains a set named
|
||||
<literal>httpd</literal>, which in turn contains an option
|
||||
definition named <literal>enable</literal> with value
|
||||
<literal>true</literal>. This means that the example above can also
|
||||
be written as:
|
||||
|
|
|
@ -40,12 +40,12 @@
|
|||
<para>
|
||||
Note that both <literal>configuration.nix</literal> and
|
||||
<literal>kde.nix</literal> define the option
|
||||
<link xlink:href="options.html#opt-environment.systemPackages"><literal>environment.systemPackages</literal></link>.
|
||||
When multiple modules define an option, NixOS will try to
|
||||
<xref linkend="opt-environment.systemPackages" />. When multiple
|
||||
modules define an option, NixOS will try to
|
||||
<emphasis>merge</emphasis> the definitions. In the case of
|
||||
<link xlink:href="options.html#opt-environment.systemPackages"><literal>environment.systemPackages</literal></link>,
|
||||
that’s easy: the lists of packages can simply be concatenated. The
|
||||
value in <literal>configuration.nix</literal> is merged last, so for
|
||||
<xref linkend="opt-environment.systemPackages" />, that’s easy: the
|
||||
lists of packages can simply be concatenated. The value in
|
||||
<literal>configuration.nix</literal> is merged last, so for
|
||||
list-type options, it will appear at the end of the merged list. If
|
||||
you want it to appear first, you can use
|
||||
<literal>mkBefore</literal>:
|
||||
|
@ -60,7 +60,7 @@ boot.kernelModules = mkBefore [ "kvm-intel" ];
|
|||
<para>
|
||||
For other types of options, a merge may not be possible. For
|
||||
instance, if two modules define
|
||||
<link xlink:href="options.html#opt-services.httpd.adminAddr"><literal>services.httpd.adminAddr</literal></link>,
|
||||
<xref linkend="opt-services.httpd.adminAddr" />,
|
||||
<literal>nixos-rebuild</literal> will give an error:
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -89,11 +89,9 @@ services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org";
|
|||
configuration value depends on itself.
|
||||
</para>
|
||||
</footnote> . For example, here is a module that adds some packages
|
||||
to
|
||||
<link xlink:href="options.html#opt-environment.systemPackages"><literal>environment.systemPackages</literal></link>
|
||||
only if
|
||||
<link xlink:href="options.html#opt-services.xserver.enable"><literal>services.xserver.enable</literal></link>
|
||||
is set to <literal>true</literal> somewhere else:
|
||||
to <xref linkend="opt-environment.systemPackages" /> only if
|
||||
<xref linkend="opt-services.xserver.enable" /> is set to
|
||||
<literal>true</literal> somewhere else:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
{ config, pkgs, ... }:
|
||||
|
|
Loading…
Reference in a new issue