GNU bug report logs - #27155
[PATCH 0/2] Support service extensions on the "final" service values

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Rutherther <rutherther <at> ditigal.xyz>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 27155 <at> debbugs.gnu.org
Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final"
Date: Thu, 10 Apr 2025 21:32:44 +0200

Hello Rutherther,

Rutherther <rutherther <at> ditigal.xyz> skribis:

> what's the state of this? Why has this been abandoned?

It was abandoned first because there wasn’t high demand (did people
learn to live with a limitation? or is it that that limitation is
acceptable in practice?) and second because I had second thoughts.

My main concern is that it could make service composition much harder to
understand.  Currently, there’s a graph of services/service types where
edges show what node influences each intermediate configuration value;
you can follow the arrows and understand what originates where
(demonstrated with <https://notabug.org/civodul/guix-explorer).

With this extension, pretty much anything could happen.  The extra
flexibility could be put to good use, but we should also pay attention
to the cost and see if we can come up with less invasive alternatives.

> For example, I would like to change the home mcron shepherd service so that it gets
> a wayland display env var.

I think it’s an example that could be solved at the Shepherd level, by
attaching essentially a key/value store to each service (the mcron
service would query the ‘wayland-display’ value of the wayland service.)

>> Right.  As discussed on IRC, one problem is ordering: if there are
>> several users of this features for a given service, you can=E2=80=99t really
>> tell what=E2=80=99s going to happen, unless the modifications happen to be
>> commutable.
>
> As for ordering, since I was using NixOS, I know a way they solve issue
> like this. Your system config there is composed of many options that
> you set to values. One option can be set multiple times, and if that
> happens, there are two possibilities - either both have same priority
> and the type is composable, then both values are used and it is
> composed with a function (ie. if you have lines type and you add
> two values, it will get merged with \n). If it is not composable,
> and error is thrown. If both have different priorities, the higher
> priority is used.

Interesting.

Note that I was using NixOS too (but long ago), and the “ambient
authority” in the NixOS module system is one thing I definitely wanted
to avoid.  By “ambient authority” I mean that any module can change any
option of the global system config; there’s no way to track which module
does what, nor whether an option that is set is used at all.

Anyway, I’m glad you’re looking into this with a fresh mind.  Hopefully
we can revisit it and find an option that brings flexibility without
chaos.  :-)

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.