Will Fancher
983d84d401
`config.system.build.kernel.config` is not actually accurate. When a kconfig is specified in the `config` argument to `kernel/build.nix` (a.k.a. `manualConfig` or `linuxManualConfig`), then `isSet` will return `true` and other queries like `isYes` will be accurate. But if a kconfig is not specified in that `config` argument, then `isSet` will return `false` and other queries will be inaccurate, e.g. `isYes` "MODULES"` can return `false` even though your `configfile` has it enabled. Note the difference between the `config` argument and the `configfile` argument. The `configfile` is how the kernel will be actually built, while `config` is merely passed through as a source of eval-time information. Importantly, neither is derived from the other *in any way*, unless `builtins.isPath configfile || allowImportFromDerivation` in which case the default value for `config` is derived from reading `configfile`. The more generic `kernel/generic.nix` (a.k.a. `buildLinux`) creates its `configfile` in a derivation, so it cannot be read at eval time by default. It calls into `kernel/build.nix`, and only passes a `config` with `CONFIG_MODULES`, `CONFIG_FW_LOADER`, and `CONFIG_RUST` set. So almost nothing in `kernel.config` is accurate in the typical case. `MODULES` happens to be one of the three that *is* accurate typically, but regardless we obviously can't rely on that since a user of `kernel/build.nix` is likely to mess it up. Even worse, `structuredExtraConfig` is not incorporated into `kernel.config` at all, which leads to the incredibly confusing scenario where a kconfig is specified in `structuredExtraConfig` but still is not represented accurately by these queries. All of this is why, in most cases, the implementation of `requiredKernelConfig` deliberately does absolutely nothing and creates an empty list of assertions, and it's all extremely confusing. With all that in mind: TODO: - The structured config used to generate the `configfile` should be reflected in the `config` argument to `kernel/build.nix`, and consequently `kernel.config`. - The three kconfigs represented by `config` in `kernel/generic.nix` now, `CONFIG_MODULES`, `CONFIG_FW_LOADER`, and `CONFIG_RUST`, should be set in the structured config. - Queries for kconfigs that we don't actually know the value of at eval time should fail to evaluate, rather than evaluating inaccurately. - Most of the ways we use these eval-time queries should instead be done at build time, so they can use the complete `configfile` rather than the incomplete eval-time `config` value. - The ones that we still want to happen at eval-time should be more prepared for the possibility that we can't know the value of arbitrary kconfigs at eval time. --- Anyway, all that is to say: I'd like for this all to be better, but am not willing to work on the kernel expressions myself at the moment, so I thought I'd write down the reasons why this change was necessary, and the extent of the problem. We had already successfully considered this issue in one place in `systemd/initrd.nix`, but it seems there are two more places where we should have taken the same care.
Nixpkgs is a collection of over 120,000 software packages that can be installed with the Nix package manager. It also implements NixOS, a purely-functional Linux distribution.
Manuals
- NixOS Manual - how to install, configure, and maintain a purely-functional Linux distribution
- Nixpkgs Manual - contributing to Nixpkgs and using programming-language-specific Nix expressions
- Nix Package Manager Manual - how to write Nix expressions (programs), and how to use Nix command line tools
Community
- Discourse Forum
- Matrix Chat
- Official wiki
- Community-maintained list of ways to get in touch (Discord, Telegram, IRC, etc.)
Other Project Repositories
The sources of all official Nix-related projects are in the NixOS organization on GitHub. Here are some of the main ones:
- Nix - the purely functional package manager
- NixOps - the tool to remotely deploy NixOS machines
- nixos-hardware - NixOS profiles to optimize settings for different hardware
- Nix RFCs - the formal process for making substantial changes to the community
- NixOS homepage - the NixOS.org website
- hydra - our continuous integration system
- NixOS Branding - NixOS branding
Continuous Integration and Distribution
Nixpkgs and NixOS are built and tested by our continuous integration system, Hydra.
- Continuous package builds for unstable/master
- Continuous package builds for the NixOS 25.11 release
- Tests for unstable/master
- Tests for the NixOS 25.11 release
Artifacts successfully built with Hydra are published to cache at https://cache.nixos.org/. When successful build and test criteria are met, the Nixpkgs expressions are distributed via Nix channels.
Contributing
Nixpkgs is among the most active projects on GitHub. While thousands of open issues and pull requests might seem like a lot at first, it helps to consider it in the context of the scope of the project. Nixpkgs describes how to build tens of thousands of pieces of software and implements a Linux distribution. The GitHub Insights page gives a sense of the project activity.
Community contributions are always welcome through GitHub Issues and Pull Requests.
For more information about contributing to the project, please visit the contributing page.
Donations
The infrastructure for NixOS and related projects is maintained by a nonprofit organization, the NixOS Foundation. To ensure the continuity and expansion of the NixOS infrastructure, we are looking for donations to our organization.
You can donate to the NixOS Foundation through SEPA bank transfers or by using Open Collective:
License
Nixpkgs is licensed under the MIT License.
Note
MIT license does not apply to the packages built by Nixpkgs, merely to the files in this repository (the Nix expressions, build scripts, NixOS modules, etc.). It also might not apply to patches included in Nixpkgs, which may be derivative works of the packages to which they apply. The aforementioned artifacts are all covered by the licenses of the respective packages.