Re: Service refactoring

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

Andy Wingo <wingo@igalia.com> skribis:

> On Sun 06 Sep 2015 23:23, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Service types and their “extends” relations form a DAG
>
> I am not sure how much ordering matters.  The reason is that the
> "extends" relations actually proceed from packages associated with a
> service, not the service itself.  It's enough to know the set of
> services and their associated extends; ordering does not appear to be
> important.  Of course we could do a topological sort on services for
> some other reason, but we don't actually need to for these purposes.

My intent was more to make relations among services explicit, rather
than specify some ordering.

> I think a two-phase configuration can work: one, in which we specify
> services like this:
>
>   (operating-system
>    ...
>    (services SERVICES))
>
> and a second in which the services are "finalized".  Finalization is a
> monadic procedure of type SERVICE SERVICES -> SERVICE.  Finalization is
> where e.g. udev would grovel the SERVICES to collect all udev extends.

It would work, yes.  But I think there’s a couple of issues worth
addressing.

An issue is that each finalization procedure is passed more information
than strictly needed.  Thus, any service can potentially influence any
other service’s configuration, which makes it harder to reason about
service composition.

Another problem is that it’s not really extensible: we’ll have to keep
adding new fields to <service> every time we think of a new way a
service needs to extend another service.  We could use an alist instead
of those record fields, but then that would make the thing sloppy (typos
would go undetected, etc.)

There’s also the assumption that each service that the user specifies
maps to a dmd service, which is not always the case (D-Bus services,
Apache modules, etc.)

Lastly, without making the “extends” relations explicit, it’s easy to
end up specifying an extension that actually extends nothing.  For
instance, you use a service that has a non-empty ‘dbus-services’ field
but forget to use the D-Bus service; Guix has no way to tell that
something’s missing.

What I suggested would address these by constraining things.  What
remains to be seen is if this can be implemented without making things
too complex.  I’ll try to experiment with this.

Thanks,
Ludo’.