Service refactoring

[ludo@gnu.org (Ludovic Courtès)]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

Andy Wingo <wingo@igalia.com> skribis:

> So then, for example, the elogind service would indicate that it
> installs udev rules, dbus interfaces, and polkit rules from the elogind
> package.  The udev service would then query all services, adding rules
> from services that indicate that they extend the udev configuration.  To
> do this I propose a "finalize-configuration" field in services.  First,
> the services are collected into a list, as they are now.  Next, Guix
> does something like this:
>
>   (define (finalize-services services)
>     (map (lambda (service)
>            ((service-finalize service) service services))
>          services))
>
> The default service-finalize will be (lambda (service services)
> service).  WDYT?

Yes, something like that.

An important characteristic is that service types extend each other:
dbus extends dmd (by adding stuff into dmd.conf), polkit extends dbus
(through .service files), elogind extends polkit (through policy files)
and dbus and udev, and so on.

Service types and their “extends” relations form a DAG like this:


[-- Attachment #2: the DAG --]
[-- Type: image/png, Size: 49482 bytes --]

[-- Attachment #3: Type: text/plain, Size: 633 bytes --]


I think we want to define a new API to capture this.  Service types will
declare which other service types they extend and how; service types
that can be extended will declare how extensions affect their
parameters.  (We need to distinguish between “service type” and “service
instance” because there can be several instances of a given type.)

Building the system works in two steps: first we propagate the
extensions down to the sinks of the DAG (such as dmd), then we
instantiate those.

Thoughts?

I’ll try to refine this and come up with a proof-of-concept for
discussion soonish.

Thanks,
Ludo’.