From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Service refactoring Date: Tue, 08 Sep 2015 12:12:03 +0200 Message-ID: <87mvwxmd8s.fsf@gnu.org> References: <87a8t3mc2v.fsf@netris.org> <87d1xyk45i.fsf@igalia.com> <87vbbn44zi.fsf_-_@gnu.org> <87fv2pe1qx.fsf@igalia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZFso-0003g0-U4 for guix-devel@gnu.org; Tue, 08 Sep 2015 06:12:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZFsk-00033n-UC for guix-devel@gnu.org; Tue, 08 Sep 2015 06:12:10 -0400 In-Reply-To: <87fv2pe1qx.fsf@igalia.com> (Andy Wingo's message of "Tue, 08 Sep 2015 10:47:34 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andy Wingo Cc: guix-devel@gnu.org Andy Wingo skribis: > On Sun 06 Sep 2015 23:23, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Service types and their =E2=80=9Cextends=E2=80=9D 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=E2=80=99s 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=E2=80=99s configuration, which makes it harder to reason about service composition. Another problem is that it=E2=80=99s not really extensible: we=E2=80=99ll h= ave to keep adding new fields to 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=E2=80=99s also the assumption that each service that the user specifi= es maps to a dmd service, which is not always the case (D-Bus services, Apache modules, etc.) Lastly, without making the =E2=80=9Cextends=E2=80=9D relations explicit, it= =E2=80=99s easy to end up specifying an extension that actually extends nothing. For instance, you use a service that has a non-empty =E2=80=98dbus-services=E2= =80=99 field but forget to use the D-Bus service; Guix has no way to tell that something=E2=80=99s 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=E2=80=99ll try to experiment with this. Thanks, Ludo=E2=80=99.