From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 05 06:07:05 2017 Received: (at 27155) by debbugs.gnu.org; 5 Jun 2017 10:07:06 +0000 Received: from localhost ([127.0.0.1]:56491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHouf-0005hY-Mh for submit@debbugs.gnu.org; Mon, 05 Jun 2017 06:07:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHoud-0005h5-VC for 27155@debbugs.gnu.org; Mon, 05 Jun 2017 06:07:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHouV-0005xs-LJ for 27155@debbugs.gnu.org; Mon, 05 Jun 2017 06:06:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHouV-0005xo-I2; Mon, 05 Jun 2017 06:06:55 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:58822 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dHouU-0001W1-UM; Mon, 05 Jun 2017 06:06:55 -0400 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Alex Kost Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values References: <20170530215850.7522-1-ludo@gnu.org> <8737bgkbsy.fsf@gnu.org> <87o9u3q15q.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 Prairial an 225 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu 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> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27155 Cc: 27155@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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.