Me, @jleightcap, @RCoeurjoly, @kiike, and @amerinor01 worked on reviving the firmware for the nitrokey family as part of Summer of Nix (cc: @fricklerhandwerk). Right now the work has bitrotted in this repo, and would benefit from active maintenance and CI. We’re thinking about putting this Nixpkgs, but the derivations don’t produce something that can be run – it’s a binary to flash onto the device. Could there be a space to have non-runnable or non-library items in Nixpkgs?
Yes, that’s fine in my view. We package fonts which also aren’t ELF binaries, and allow cross‐compilation to all sorts of exotic architectures. If we package the tools to flash it, that’s even better.
How about adding a small script (just an echo) as mainProgram that states that this derivation is intended to produce a blob that is intended to be flashed on a Nitrokey?
The closest that comes to mind is probably the derivation(s) for uboot, which also produce binary images for devices different from the build host.
How about adding a small script (just an echo) as mainProgram that states that this derivation is intended to produce a blob that is intended to be flashed on a Nitrokey?
You can add a mainProgram like that if you want – I guess it could even tell you the command to flash that firmware – but it’s not necessary. There’s no requirement that Nixpkgs packages be application binaries for the build platform.
I feel this is stretching the imagination a bit of what a package is. This doesn’t feel like something I’d install on my system and use daily, in contrast to e.g. a WiFi firmware.
What is the use case of this? To automatically update the firmware when the key is inserted? Or would this not be a package to install at all? Then it just feels like ‘there is some infra that builds it for me so I do not have to’ which makes me slightly uncomfortable. But maybe I’m overthinking this. This feels like a great example where flakes would make sense, you just build the flake once a year, flash it and be done.
But let me know what you think, it just feels somewhat weird to me to package this in nixpkgs.
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.