[bug#68757] [PATCH] services: dns: Add unbound service

[Ludovic Courtès]

Hi,

Sören Tempel <soeren@soeren-tempel.net> skribis:

> Prior to submitting this patch I was experimenting with both records and
> alists for the Unbound configuration abstraction. Unbound has **a lot**
> of configuration options and new options are constantly getting added by
> upstream, see unbound.conf(5). Therefore, supporting them through a
> record type with fields for each configuration option requires a lot of
> code. Furthermore, it will require constant maintenance to keep up with
> new upstream options.

Right.

> I looked at prior art and noticed that the Nix service configuration for
> unbound just uses a plain hash with string keys [1]. This seemed like a
> good way to deal with the complexity of unbound.conf, hence I opted for
> a similar approach here. I don't think it's feasible to model the
> configuration using a record type with several hundred fields and, as rde
> uses an alist-based approach for services with similar complexity, I
> don't think its unheard of in the Guix world either. While it is not as
> “type safe” as a record-based approach (e.g. you can create semantically
> invalid unbound configurations), it offers good forwards compatibility
> and requires less Scheme code.
>
> In theory, it would be possible to model sections with less options
> (e.g. the ‘remote-control’ or ‘server’ option) using records. However,
> using alists for some sections and records for others seems inconsistent
> to me.
>
> Please let me know what you think so I can revise this accordingly.

The usual approach for services in Guix is to have a record for the most
common options (or for all the options if that doing so can be
automated, as was done with Dovecot) and an “escape hatch” that lets
users insert raw config text.  Key/value alists are not a common idiom.

I would suggest sticking to this model as much as possible.  Perhaps
key/value alists would be preferable as an escape hatch than raw
strings?

Now, I don’t use Unbound, so I can only give general advice based on
what’s usually done in Guix.  Maybe ‘knot-service-type’ is a useful
source of inspiration.

HTH!

Ludo’.