nixpkgs/nixos
WilliButz d7ef2defda
nixos/repart-image: refactor to use mkDerivation
As a follow-up to https://github.com/NixOS/nixpkgs/pull/294096 this
should further improve the flexibility around building OS images with
systemd-repart:

* Previously the attribute set `compression` needed to be fully
  populated, including `algorithm` and `level` because
  `compression.enable` was evaluated by bash, after being interpolated
  as strings into the `buildCommand`. Now it's sufficient to pass
  `compression.enable = false` to the builder, e.g. in `overrideAttrs`,
  to disable the compression.
* Using mkDerivation allows for much more customization than the
  previously used `runCommand`, making use of phases and pre/post hooks.
  This is especially helpful for building multiple images from the same
  system configuration, e.g. to build an image `Y` based on a partially
  built raw image `X`,  by injecting a UKI that depends on `X` into a
  defered ESP.
* Before this change it was non-trivial to conduct further manipulations
  on the amended repart definitions. Now, the definitions that
  systemd-repart uses to build the image can be easily manipulated in
  `postPatch` or `preBuild`.

Aside from this, the build is now executed in the build directory, rather
than `$out`. This allows references to relative paths in the build
environment to be used, especially for `--definitions`, which previously
required an absolute path.
2024-03-21 11:37:43 +01:00
..
doc/manual Merge pull request #291305 from gbtb/nvtop-310 2024-03-20 09:58:40 +02:00
lib Merge pull request #293710 from B4dM4n/networkd-policy-rule-port-range 2024-03-17 12:36:30 -07:00
maintainers Merge pull request #287100 from mkg20001/lxd-fix-config 2024-02-15 07:48:05 -05:00
modules nixos/repart-image: refactor to use mkDerivation 2024-03-21 11:37:43 +01:00
tests Merge pull request #295387 from majiru/drawterm-update 2024-03-20 17:19:26 +01:00
COPYING
default.nix
README.md
release-combined.nix nixos/release: nfs3 -> nfs4 in all tested sets 2024-02-27 18:23:51 +03:00
release-small.nix nixos/release: nfs3 -> nfs4 in all tested sets 2024-02-27 18:23:51 +03:00
release.nix nixos/release: add Plasma 6 ISO variant 2024-02-28 18:49:33 +03:00

NixOS

NixOS is a Linux distribution based on the purely functional package management system Nix. More information can be found at https://nixos.org/nixos and in the manual in doc/manual.

Testing changes

You can add new module to your NixOS configuration file (usually its /etc/nixos/configuration.nix). And do sudo nixos-rebuild test -I nixpkgs=<path to your local nixpkgs folder> --fast.

Commit conventions

  • Make sure you read about the commit conventions common to Nixpkgs as a whole.

  • Format the commit messages in the following way:

    nixos/(module): (init module | add setting | refactor | etc)
    
    (Motivation for change. Link to release notes. Additional information.)
    

    Examples:

    • nixos/hydra: add bazBaz option

      Dual baz behavior is needed to do foo.

    • nixos/nginx: refactor config generation

      The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).

Reviewing contributions

When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break peoples installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.

Module updates

Module updates are submissions changing modules in some ways. These often contains changes to the options or introduce new options.

Reviewing process:

  • Ensure that the module maintainers are notified.
    • CODEOWNERS will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
  • Ensure that the module tests, if any, are succeeding.
    • You may invoke OfBorg with @ofborg test <module> to build nixosTests.<module>
  • Ensure that the introduced options are correct.
    • Type should be appropriate (string related types differs in their merging capabilities, loaOf and string types are deprecated).
    • Description, default and example should be provided.
  • Ensure that option changes are backward compatible.
    • mkRenamedOptionModuleWith provides a way to make renamed option backward compatible.
    • Use lib.versionAtLeast config.system.stateVersion "23.11" on backward incompatible changes which may corrupt, change or update the state stored on existing setups.
  • Ensure that removed options are declared with mkRemovedOptionModule.
  • Ensure that changes that are not backward compatible are mentioned in release notes.
  • Ensure that documentations affected by the change is updated.

Sample template for a module update review is provided below.

##### Reviewed points

- [ ] changes are backward compatible
- [ ] removed options are declared with `mkRemovedOptionModule`
- [ ] changes that are not backward compatible are documented in release notes
- [ ] module tests succeed on ARCHITECTURE
- [ ] options types are appropriate
- [ ] options description is set
- [ ] options example is provided
- [ ] documentation affected by the changes is updated

##### Possible improvements

##### Comments

New modules

New modules submissions introduce a new module to NixOS.

Reviewing process:

  • Ensure that all file paths fit the guidelines.
  • Ensure that the module tests, if any, are succeeding.
  • Ensure that the introduced options are correct.
    • Type should be appropriate (string related types differs in their merging capabilities, loaOf and string types are deprecated).
    • Description, default and example should be provided.
  • Ensure that module meta field is present
    • Maintainers should be declared in meta.maintainers.
    • Module documentation should be declared with meta.doc.
  • Ensure that the module respect other modules functionality.
    • For example, enabling a module should not open firewall ports by default.

Sample template for a new module review is provided below.

##### Reviewed points

- [ ] module path fits the guidelines
- [ ] module tests succeed on ARCHITECTURE
- [ ] options have appropriate types
- [ ] options have default
- [ ] options have example
- [ ] options have descriptions
- [ ] No unneeded package is added to `environment.systemPackages`
- [ ] `meta.maintainers` is set
- [ ] module documentation is declared in `meta.doc`

##### Possible improvements

##### Comments