Inclusion of device firmwares in Nixpkgs

Development Nixpkgs Architecture
8

Very generally, a Nixpkgs package is just a derivation that adheres to some (for now conventionally) standardised output structure. For example:

  • If a package has a /bin directory, its contents should be executable files. This standard is used to build PATH in various contexts (nix-shell, NixOS, nix-env, etc.). This is the most common interpretation of a package.
  • If a package has a /lib directory, it contains library files that can be linked to, made use of by e.g. buildInputs and to build LD_LIbRARY_PATH. There’s a lot of packages that only have a /lib directory and no /bin, e.g. pkgs.libpng
  • If a package has a /lib/python3/site-packages directory, it contains Python libraries, which e.g. propagatedBuildInputs from buildPythonApplication makes use of, but can also be used to build PYTHON_PATH
  • If a package has a /lib/systemd directory, it contains systemd units, which is used by e.g. NixOS, but can also be used by other systemd distros.
  • If a package has a /share/fonts directory, it contains fonts, which is made use of by e.g. the fonts.packages option.
  • etc.

NixOS also has a very generic way for composing many packages exposing such directories into a single location (this can be understood as “installing”): environment.systemPackages and environment.pathsToLink, getting composed into /run/current-system/sw.

So it’s definitely not a problem to put derivations into Nixpkgs that don’t contain binaries. Whether a derivation is a good fit for Nixpkgs depends on entirely orthogonal factors, which are documented to a degree here.

9 Likes