Re: Service refactoring

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> 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 that Ludovic's proposal is excellent, and I'm sympathetic to his
desire to minimize the amount of information services have about each
other, but I have one concern:

Will we ever encounter a case where two services need to be told about
each other?  More generally, the "needs to know about" graph might
contain cycles.  Even if there's not one today, we may encounter one
tomorrow.  I don't see a compelling reason to restrict this structure to
be a DAG, and such a restriction may cause problems for us later.

What do you think?

       Mark