Currently, kernel config options whose value is "yes" always override
options whose value is "no".
This is not always desired.
Generally speaking, if someone defines an option to have the value
"no", presumably they are disabling the option for a reason, so it's
not always OK to silently enable it due to another, probably unrelated
reason.
For example, a user may want to reduce the kernel attack surface and
therefore may want to disable features that are being enabled in
common-config.nix.
In fact, common-config.nix was already silently enabling options that
were intended to be disabled in hardened/config.nix for security
reasons, such as INET_DIAG.
By eliminating the custom merge function, these config options will
now use the default module option merge functions which make sure
that all options with the highest priority have the same value.
A user that wishes to override an option defined in common-config.nix
can currently use mkForce or mkOverride to do so, e.g.:
BINFMT_MISC = mkForce (option no);
That said, this is not going to be necessary in the future, because
the plan is for kernel config options defined in nixpkgs to use a
lower priority by default, like it currently happens for other module
options.
The notification daemon is just one part of XFCE that is, to the best of
my understanding, not particularly related to it being desktop or not —
for instance, not more related than the session manager or the like.
We are running over 6000 tests by now and they take around 5 minutes
on faster machines and tests alot of components that endusers will not
actually be using. It is sufficient if we run them on package upgrades
and in the passthrough test.
This dependency has been added in 65eae4d, when NixOS switched to
systemd, as a substitute for the previous udevtrigger and hasn't been
touched since. It's probably unneeded as the upstream unit[1] doesn't
do it and I haven't found any mention of any problem in NixOS or the
upstream issue trackers.
[1]: https://gitlab.com/libvirt/libvirt/-/blob/master/src/remote/libvirtd.service.in
This will make it easier to track specifically where queries are being
made from (assuming a `log_line_prefix` that includes `%a` in the
postgres configuration).
The manual mentions how "[config and pkgs] are explained later". Added a link
to where they are explained, and a hint pointing to the NIX_PATH variable.
the nix store may contain hardlinks: derivations may output them
directly, or users may be using store optimization which automatically
hardlinks identical files in the nix store.
The presence of these links are intended to be a 'transparent'
optimization. However, when creating a squashfs image, the image
will be different depending on whether hard links were present
on the filesystem, leading to reproducibility problems.
By passing '-no-hardlinks' to mksquashfs the files are stored
as duplicates in the squashfs image. Since squashfs has support
for duplicate files this does not lead to a larger image.
For more details see
https://github.com/NixOS/nixpkgs/issues/114331
