A change made in #166308 added `networking.resolvconf.package` to the
`environment.systemPackages` list, so it is installed as part of the
system image. However it does so unconditionally, meaning that even if
the `config.networking.resolvconf.enable` is set to false the package
listed in the `networking.resolvconf.package` would still be intalled.
This change makes it so the package installation will depend on the
status of the `config.networking.resolvconf.enable` option instead.
markdown can't represent the difference without another extension and
both the html manual and the manpage render them the same, so keeping the
distinction is not very useful on its own. with the distinction removed
we can automatically convert many options that use <code> tags to markdown.
the manpage remains unchanged, html manual does not render
differently (but class names on code tags do change from "code" to "literal").
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
For systems without internet connections, it doesn't make sense to
require the existence of an /etc/resolv.conf file to disable
resolvconf, so let's expose networking.resolveconf.enable as a public
option that can be set to false.
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
This is a refactor of how resolvconf is managed on NixOS. We split it
into a separate service which is enabled internally depending on whether
we want /etc/resolv.conf to be managed by it. Various services now take
advantage of those configuration options.
We also now use systemd instead of activation scripts to update
resolv.conf.
NetworkManager now uses the right option for rc-manager DNS
automatically, so the configuration option shouldn't be exposed.
