Andy Wingo <wi...@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:
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’.
