Since the output of `lib.systems.elaborate` contains functions, an
equality check with `==` does not suffice, `lib.systems.equals` should
be used instead.
Currently there are a bunch of really wacky hacks required to get nixpkgs
path correctly set up under flake configs such that `nix run
nixpkgs#hello` and `nix run -f '<nixpkgs>' hello` hit the nixpkgs that
the system was built with. In particular you have to use specialArgs or
an anonymous module, and everyone has to include this hack in their
own configs.
We can do this for users automatically.
I have tested these manually with a basic config; I don't know if it is
even possible to write a nixos test for it since you can't really get a
string-with-context to yourself unless you are in a flake context.
The version option is needed if you want to implement partition &
systemd-boot based A/B booting where the version information is encoded
in the files on the ESP. See systemd-sysupate docs for more details on
this:
https://www.freedesktop.org/software/systemd/man/latest/sysupdate.d.html
Note, however, that this is not *only* useful for systemd-sysupdate but
also for other similar updating tools/mechanisms.
see #277861. as the module list grows the argument size in the
lazy-options nix call grows, eventually reaching a hard limit and
causing the build to fail. writing the list to a file instead and import
it instead of providing it directly circumvents this.
All the locate versions we have support LOCATE_PATH, so just use that
instead of adding indirections all over the place AND forcing people
to rebuild their locate implementation if they want the path changed.
- Move contents of README.md from
nixos/modules/installer/tools/manpages/ to
nixos/doc/manual/contributing-to-this-manual.chapter.md.
- Don't mention DocBook as its obsolete and too specific.
- Rename derivation attribute name of configuration.nix(5) manual page,
both on the `contributing-to-this-manual.chapter.md`, and in other
places.
Since each such `nixos-*` tool has it's own derivation, exposed in pkgs,
There is no point in separating the manuals from the packages. If
someone wishes to have the tools without the manuals, they can use
meta.outputsToInstall to disable the installation of the manpages of
these packages. This Fixes#244450.
they're no longer necessary for us and will almost definitely start to
rot now (like commonmark and asciidoc outputs did previously). most
existing users seem to take the docbook output and run it through pandoc
to generate html, those can easily migrate to use commonmark instead.
other users will hopefully pipe up when they notice that things they rely
on are going away.
optionsUsedDocbook has only been around for one release and only exposed
to allow other places to generate warnings, so that does not deserve
such precautions.
it's been long in the making, and with 23.05 out we can finally disable
docbook option docs and default to markdown instead. this brings a
massive speed boost in manual and manpage builds, so much so that we may
consider enabling user module documentation by default.
we don't remove the docbook support code entirely yet because it's a lot
all over, and probably better removed in multiple separate changes.
This allows modules that declare their class to be checked.
While that's not most user modules, frameworks can take advantage
of this by setting declaring the module class for their users.
That way, the mistake of importing a module into the wrong hierarchy
can be reported more clearly in some cases.
