From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHovd-00013A-Cx for guix-patches@gnu.org; Mon, 05 Jun 2017 06:08:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHova-00075D-9M for guix-patches@gnu.org; Mon, 05 Jun 2017 06:08:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:53814) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dHova-00074u-5n for guix-patches@gnu.org; Mon, 05 Jun 2017 06:08:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dHova-0005ij-0c for guix-patches@gnu.org; Mon, 05 Jun 2017 06:08:02 -0400 Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20170530215850.7522-1-ludo@gnu.org> <8737bgkbsy.fsf@gnu.org> <87o9u3q15q.fsf@gmail.com> Date: Mon, 05 Jun 2017 12:06:51 +0200 In-Reply-To: <87o9u3q15q.fsf@gmail.com> (Alex Kost's message of "Sun, 04 Jun 2017 17:26:41 +0300") Message-ID: <8760gag344.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Alex Kost Cc: 27155@debbugs.gnu.org Alex Kost skribis: > Ludovic Court=C3=A8s (2017-06-03 23:21 +0200) wrote: [...] >> Not liking the =E2=80=9Csudo=E2=80=9D aspect of this patch, I thought it= would be >> natural if service types could control how customizations apply. That >> way, the PAM or /etc service could still guarantee, for instance, that >> customization does not add or remove entries, and so on. > > Ouch, that's what I don't like. I think a full control is better. > You'll never know what a user might want to do, and giving a user a full > freedom (even to break a system!) would be a great feature. So I'm > against such guarantees that strict users in modifying their systems. Just to be clear: I do want users to be able to modify their system as they see fit. The argument is about how we should structure these modifications. In the end, people can always define and use their own services, or even =E2=80=98set!=E2=80=99 things. But if we can provide users with control ov= er their system in a structured way, I think it=E2=80=99s beneficial: they can do co= mplex customizations of their system and still reason about them. >> So at this point, I started wondering whether we should just allow >> service types to declare several extension points. So for PAM, we=E2=80= =99d do: >> >> (define pam-service-addition >> ;; The extension point to add PAM services. >> (service-extension-point >> (compose concatenate) >> (extend append))) >> >> (define pam-service-cutomization >> ;; The extension point to customize PAM services. >> (service-extension-point >> (compose compose) >> (extend append))) >> >> (define pam-root-service-type >> (service-type (name 'pam) >> (extensions (list (service-extension etc-service-type >> /etc-entry))) >> >> (extension-points (list pam-service-addtion >> pam-service-customization)))) >> >> But then =E2=80=98service-extension=E2=80=99 would need to specify not o= nly the target >> service type but also the target extension point, which means more >> boilerplate, etc. > > I don't have a deep understanding of services, but your suggestion seems > (to me) to have the following downsides: > > - More additional work =E2=80=93 to determine (and implement) what aspect= s of > services should and what should not be modified by a user. > > - Less freedom (comparing to your previous solution) for users in > modifying services. I see what you mean. Ludo=E2=80=99, who thinks some more.