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.
Avoids confusion: `vim-full`'s build-time features are configurable, but both
`vim` and `vim-full` are *customizable* (in the sense of user configuration).
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.
We can't actually get metrics for a virtual disk drive so the exporter
fails to start with 0.9.x.
Instead let's just make sure it said that /dev/vda was unavailable.
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.
