GNU bug report logs - #27155
[PATCH 0/2] Support service extensions on the "final" service values

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alex Kost <alezost <at> gmail.com>
Cc: 27155 <at> debbugs.gnu.org
Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values
Date: Mon, 05 Jun 2017 12:06:51 +0200

Alex Kost <alezost <at> gmail.com> skribis:

> Ludovic Courtès (2017-06-03 23:21 +0200) wrote:

[...]

>> Not liking the “sudo” 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
‘set!’ things.  But if we can provide users with control over their
system in a structured way, I think it’s beneficial: they can do complex
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’d 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 ‘service-extension’ would need to specify not only 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 – to determine (and implement) what aspects 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’, who thinks some more.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.