In some recent version evcc started requiring `getent` in the PATH, or
else it would fail to start.
It also now requires an sqlite database, which it tries to create a
directory for at `$HOME/.evcc`, so we now need to provide a
StateDirectory.
Some implementation notes:
* cups-pdf, and cups-pdf-to-pdf,
support multiple instances with differing configurations.
This can be accomplished by creating multiple configuration
files with names `cups-pdf-{instance-name}.conf`.
The Nixos module supports this feature by providing
the option `instances` which is an attrset
mapping instance names to instance configurations.
To simplify module usage,
an instance `pdf` is created by default.
* To use a cups-pdf instance, one also needs
a cups queue that connects to the backend.
The module does this automatically by default,
using the `hardware.printers.ensurePrinters`.
It uses one of the ppd files which is
included in the cups-pdf package.
If this isn't desired (e.g. because printer queues
should be created by hand, or configured differently),
the `installPrinter` option can be turned off
(for each instance separately).
* In our configuration, cups calls external programs
using the `cups` account and the `lp` group.
cups-pdf refuses to operate without root privileges,
likely because it needs to change the
ownership of it output pdf files so that
(only) the print job's owner can access them.
The module installs a suid root wrapper for the backend
program that can only be called by the `lp` group.
The cups-pdf package is replaced by a wrapper
package which calls the suid root wrapper.
So cups can call its backend programs as usual.
This fixes a typo that prevented the fish keybindings from being loaded.
Also, the keybindings are now only loaded if programs.skim.keybindings
is true, which matches the behavior for bash and zsh.
Setting up the DeviceAllow list with explicitly configured devices was a
nice idea, but sometimes a configured device (`/dev/nvme0n1` an NVMe
namespace) has a parent device (`/dev/nvme0`) that smartctl needs to
access to query metrics.
Falling back to the block and character definitions is probably a valid
fallback.
We separate the different steps (injecting the toplevel and injecting
the specialisations) so that it's easy to document what each snippet is
actually doing.
