When running nixos-rebuild -I, the man page just said "-I path" which could be interpreted as
"just a path to nixpkgs", which in fact it actually has the same meaning as NIX_PATH.
This is now made clear in the manual, so that when grepping "-I" and "NIX_PATH" one quickly finds
the format of the option.
I don't know how to link to the "nix manual" as stated in the docbook, so I left that as it is.
Additionally, it wasn't clear to me how to actually build the man pages and view the changes I made.
That's now in the contributing-to-this-manual.chapter.md.
Avoids confusion: `vim-full`'s build-time features are configurable, but both
`vim` and `vim-full` are *customizable* (in the sense of user configuration).
I'm well aware that this issue is currently under discussion[1] and that
these things may change. Also, please don't misinterpret this as an
attempt to end the discussion.
This topic made it obvious that people are surprised by the way this
issue is handled and only finding out about this unwritten rule because
of asking is not a good state IMHO, so I decided to document the
following things:
* Right now we drop kernels as soon as they get out of maintenance (LTS
kernels even before the next stable NixOS that will exceed their
lifespan).
* The `latestCompatibleLinuxPackages` attribute from ZFS isn't
monotonic since latest only refers to the latest supported kernel.
* In fact `latestCompatibleLinuxPackages` doesn't seem to be documented
at all in the manual, so I also did that.
[1] https://discourse.nixos.org/t/aggressive-kernel-removal-on-eol-in-nixos/23097
Adds a new option for backup jobs `inhibitsSleep` which prevents
the system from going to sleep while a backup is in progress.
Uses `systemd-inhibit`, which holds a "lock" that prevents the
system from sleeping while the process it invokes is running.
This did require wrapping the existing backup script using
`writeShellScript` so that it could be run by `systemd-inhibit`.
When using the declarative shared folder configuration for resilio sync
it is now possible to pass a path from which to read the secret should
be read at runtime. The path will not be added to the nix store.
The 'secret' parameter to specify the secret directly is still
supported. This option will still store the secret in the nix store.
This commit follows the pattern described in this issue, for upstream
programs that do not provide support for setting a password using a
file: https://github.com/NixOS/nixpkgs/issues/24288
Add a section on ordering option definitions.
Also mention `mkDefault` in the section on `mkOverride`.
Clarify the code a bit by renaming `defaultPriority` to
`defaultOverridePriority` and introducing `defaultOrderPriority`.
The placement of this option under `nix` was misleading, as it is not
configuration of the Nix daemon, but rather configuration of the NixOS
boot process and how it mounts the Nix store. As such, make it an option
of `boot` to clarify what it actually affects, and imply that it will
only take effect on a reboot.
Since it no longer has the context of nix, adjust the name to include
it.
Packages built with `haskellPackages.callHackage` won't be rebuilt when
updating `all-cabal-hashes`.
The removed comment was keeping a reference to the `cabal2nix` call,
which itself depends on `all-cabal-hashes`, in order to keep this file
during a garbage collection.
The tradeoff is between:
- The current behavior: a mass rebuild, any change of `all-cabal-hashes`
triggers a rebuild of all the packages built with `callHackage` and
packages which depend on them. This can take hours, and may happen
after a "small" unrelated change (i.e. an user is bumping
`all-cabal-hashes` in order to use a new package from hackage). It
also have global impacts in a project (long rebuild in CI, new entries
in cache, developers need to fetch the new entries, ...). In this
context, `cabal2nix` entries are not garbage collected.
- The new behavior: No mass rebuild, but `cabal2nix` derivations need to
be recomputed after a garbage collection. This is usually fast (a few
seconds by call), linear with the number of calls and should not
happen a lot (i.e. users are not garbage collecting everyday).
See https://github.com/NixOS/nixpkgs/issues/194751 for details.
This also removes automatic enablement/mounting of instance store swap
devices and ext3 filesystems. This behaviour is strongly opinionated
and shouldn't be enabled by default.
The unionfs behaviour never took effect anyway, because the AMI
manifest path only exists for instance store-backed AMIs, which have
not been supported by nixpkgs since
84742e2293 (2019).
Enabling Wayland support by default prevents use of XWayland on Wayland
systems, while correctly falling back to X11 when Wayland is
unavailable in the current session.
With the current packaging many people unnecessarily rely on the
`firefox` attribute, which is suggested by nixos-generate-config, which
in turn makes their Firefox use XWayland, when it shouldn't, which
causes bugs with GNOME on Wayland:
https://discourse.nixos.org/t/firefox-all-black-when-first-launched-after-login/21143
Using the Wayland-enabled Firefox was tested on pure X11 systems by
contributors on the #nix-mozilla:nixos.org room and we are confident
this change will not cause severe regressions.
Even better, people can now toggle `MOZ_ENABLE_WAYLAND=<0|1>` in their
environment to override this decision, should they feel the need to do
so.
