Andy Wingo <wi...@igalia.com> skribis: > On Sun 06 Sep 2015 23:23, l...@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’.
