1d7ee9ff09
The Nixpkgs documentation on the linux kernel builders focused on using and extending kernels that were already packaged, but never mentioned that it's possible to also build a kernel almost "from scratch". The NixOS documentation went a bit deeper on manual linux kernel configs, but that information wasn't particularly NixOS-specific. This commit consolidates the information related to building the kernel on Nixpkgs's documentation, while keeping any additional NixOS-specific information on NixOS's documentation. An additional README.md was created for contributor-facing documentation. |
||
---|---|---|
.. | ||
build-helpers | ||
contributing | ||
development | ||
doc-support | ||
functions | ||
hooks | ||
languages-frameworks | ||
module-system | ||
old | ||
packages | ||
stdenv | ||
using | ||
build-helpers.md | ||
common.nix | ||
contributing.md | ||
default.nix | ||
development.md | ||
functions.md | ||
lib.md | ||
manpage-urls.json | ||
manual.md.in | ||
overrides.css | ||
preface.chapter.md | ||
README.md | ||
shell.nix | ||
stdenv.md | ||
style.css | ||
using-nixpkgs.md |
Contributing to the Nixpkgs manual
This directory houses the sources files for the Nixpkgs manual.
You can find the rendered documentation for Nixpkgs unstable
on nixos.org.
The rendering tool is nixos-render-docs, sometimes abbreviated nrd
.
Docs for Nixpkgs stable are also available.
If you're only getting started with Nix, go to nixos.org/learn.
Contributing to this documentation
You can quickly check your edits with nix-build
:
$ cd /path/to/nixpkgs
$ nix-build doc
If the build succeeds, the manual will be in ./result/share/doc/nixpkgs/manual.html
.
devmode
The shell in the manual source directory makes available a command, devmode
.
It is a daemon, that:
- watches the manual's source for changes and when they occur — rebuilds
- HTTP serves the manual, injecting a script that triggers reload on changes
- opens the manual in the default browser
Syntax
As per RFC 0072, all new documentation content should be written in CommonMark Markdown dialect.
Additional syntax extensions are available, all of which can be used in NixOS option documentation. The following extensions are currently used:
Tables
Tables, using the GitHub-flavored Markdown syntax.
Anchors
Explicitly defined anchors on headings, to allow linking to sections. These should be always used, to ensure the anchors can be linked even when the heading text changes, and to prevent conflicts between automatically assigned identifiers.
It uses the widely compatible header attributes syntax:
## Syntax {#sec-contributing-markup}
Note
NixOS option documentation does not support headings in general.
Inline Anchors
Allow linking arbitrary place in the text (e.g. individual list items, sentences…).
They are defined using a hybrid of the link syntax with the attributes syntax known from headings, called bracketed spans:
- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
Automatic links
If you omit a link text for a link pointing to a section, the text will be substituted automatically. For example [](#chap-contributing)
.
This syntax is taken from MyST.
Roles
If you want to link to a man page, you can use {manpage}`nix.conf(5)`
. The references will turn into links when a mapping exists in doc/manpage-urls.json
.
A few markups for other kinds of literals are also available:
{command}`rm -rfi`
{env}`XDG_DATA_DIRS`
{file}`/etc/passwd`
{option}`networking.useDHCP`
{var}`/etc/passwd`
These literal kinds are used mostly in NixOS option documentation.
This syntax is taken from MyST. Though, the feature originates from reStructuredText with slightly different syntax.
Admonitions
Set off from the text to bring attention to something.
It uses pandoc’s fenced div
s syntax:
::: {.warning}
This is a warning
:::
The following are supported:
Definition lists
For defining a group of terms:
pear
: green or yellow bulbous fruit
watermelon
: green fruit with red flesh
Commit conventions
-
Make sure you read about the commit conventions common to Nixpkgs as a whole.
-
If creating a commit purely for documentation changes, format the commit message in the following way:
doc: (documentation summary) (Motivation for change, relevant links, additional information.)
Examples:
-
doc: update the kernel config documentation to use
nix-shell
-
doc: add information about
nix-update-script
Closes #216321.
-
-
If the commit contains more than just documentation changes, follow the commit message format relevant for the rest of the changes.