all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: "Sören Tempel" <soeren@soeren-tempel.net>
Cc: 68757@debbugs.gnu.org
Subject: [bug#68757] [PATCH] services: dns: Add unbound service
Date: Tue, 27 Feb 2024 11:14:51 +0100	[thread overview]
Message-ID: <87frxei57o.fsf@gnu.org> (raw)
In-Reply-To: <2O0HFY6AW6QUG.320OU5YPLJHHZ@8pit.net> ("Sören Tempel"'s message of "Sat, 24 Feb 2024 19:45:44 +0100")

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’.




      reply	other threads:[~2024-02-27 10:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-27 12:10 [bug#68757] [PATCH] services: dns: Add unbound service soeren
2024-02-18 15:18 ` Ludovic Courtès
2024-02-24 18:45   ` Sören Tempel
2024-02-27 10:14     ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87frxei57o.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=68757@debbugs.gnu.org \
    --cc=soeren@soeren-tempel.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.