bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Am Sonntag, dem 07.05.2023 um 21:05 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Hi Maxim,
> > 
> > Am Sonntag, dem 07.05.2023 um 14:12 -0400 schrieb Maxim Cournoyer:
> > > My focus on this series was making sure the configuration is
> > > easy(er)
> > > to reason with and that it works out of the box for the most
> > > part.
> > Obsoleting the group field does imho not significantly ease its
> > use.
> > It rather makes its non-ootb use harder, because you now have to
> > edit
> > two operating-system fields, without changing anything for the ootb
> > use.
> 
> If you haven't tried that already, I'd like to give you the following
> challenge: with the current MPD service, are you able to configure it
> so that it works as your user, touching the minimum amount of
> configuration switches (as you'd do if you were a new MPD service
> user getting started?).
I mean, I do have an unfair advantage at this challenge, but:

  (define* (by proc value #:optional (= equal?))
    (lambda (record)
      (= (proc record) value)))

  (service mpd-service-type
           (mpd-configuration
            (user (find (by user-account-name my-user-name) users))
            (group (find (by user-group-name "users") %base-groups))))

If you want, you can also make that a match-lambda.

> With this series I opinionated on the side that less is better,
> coming from the realization that configuring a working MPD was
> already quite the challenge (less after this series, if it succeeds
> at its goal).  In my opinion, the main two use cases for configuring
> the services user/group probably are:
> 
> 1. you want to run it as an existing user
> 2. you want it to run as its own user
> 
> The defaults cover 2, while for 1 you don't have a need to configure
> a group for it, since an existing user will also already have an
> existing group (and the <user-account> captures such group).
Seeing how you write about "the main two use cases", I think either
there is a third use case not mentioned or you are underselling the
extent of the second use case.

> > > It puts the issue aside; if you can't configure a mismatched
> > > group, you can't shoot yourself in the foot.
> > No, it doesn't: Since it pulls in the groups field into "stuff you
> > need to worry about when editing your MPD service", it actually
> > exacerbates the issue.  Yes, the API is awkward, but it does help
> > making mpd-service-type self-contained.
> 
> The thing is that the 'group' field of mpd-service-type has a
> default, which is easy to forget (because it's duplicated from a
> <user-account> object and you may reasonably expect the service to
> default to the specified user-account's group).  But that's not easy
> to achieve.  I tried.
I mean, if you want to serialize the user account's group, by all means
go ahead, but the group field should stay semantically intact for the
case that user:group are provided as strings.  Well, as it turns out,
you don't need to serialize the user or the group to the config file,
so that's not even an issue holding us back.

> > 
Cheers