[bug#68716] [PATCH gnome-team RFC 1/3] services: Modularise gnome-desktop-configuration.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Donnerstag, dem 25.01.2024 um 18:12 +0100 schrieb Vivien Kraus:
> Hello!
> 
> Thank you for this series.
> 
> Le jeudi 25 janvier 2024 à 16:35 +0100, Liliana Marie Prikler a
> écrit :
> >  (define (gnome-udev-rules config)
> >    "Return the list of GNOME dependencies that provide udev rules."
> > -  (let ((gnome (gnome-desktop-configuration-gnome config)))
> > -    (gnome-packages gnome '("gnome-settings-daemon"))))
> > +  (let* ((gnome (gnome-desktop-configuration-gnome config))
> > +         (shell (gnome-desktop-configuration-shell config)))
> > +    (or (any (match-lambda
> > +               ((and pkg (= package-name "gnome-settings-daemon"))
> > +                (list pkg))
> > +               (_ #f))
> > +             shell)
> > +        (and (maybe-value-set? gnome)
> > +             (gnome-packages gnome '("gnome-settings-daemon")))
> > +        (raise
> > +         (condition
> > +          (&error-location
> > +           (location (gnome-desktop-configuration-source-location
> > config)))
> > +          (&message (message (G_ "Missing gnome-settings-
> > daemon"))))))))
> >  
> Is there a reason why we can’t just add everything (like what your
> new gnome-profile function does)?
> 
> As far as I understand, the user doesn’t have a say over which
> individual rules will be used, among the rules that come from the
> same package. So if we want the user to have full control over the
> rules that are picked, then the current configuration record does not
> allow sufficient precision.
> 
> Also, we now have udev hardware files. I’m not sure we have any GNOME
> packages that install hardware files, but the user might have some.
> The gnome-udev-rules function name is misleading now (sorry, my bad,
> I should have renamed it when the udev service changed), because
> every package listed here will also have its hardware files
> installed, not just rules. If you want to pick rules separately from
> hardware files, you have to use file->udev-rule, file->udev-hardware
> (or udev-rule and udev-hardware) from (gnu services base).
That is a good point that I've been debating with myself.  For v1, I
simply aimed at service equivalence, but I have yet to decide whether
that's desirable or useful.

I don't want to simply drop all packages into udev-service-type,
though, unless there's some clever filtering going on behind the back.
I'm not sure at which stage we could efficiently check for the presence
of these magic directories and add them.

> > @@ -1422,7 +1566,7 @@ (define gnome-desktop-service-type
> >            (service-extension polkit-service-type
> >                               gnome-polkit-settings)
> >            (service-extension profile-service-type
> > -                             (compose list gnome-desktop-
> > configuration-gnome))))
> > +                             gnome-profile)))
> >     (default-value (gnome-desktop-configuration))
> >     (description "Run the GNOME desktop environment.")))
> I think the gnome-desktop-service-type could be easily made
> extensible, so that e.g a gnome-circle-service-type could add all the
> circles applications in their respective sections.
> 
> Maybe it could be extended with other instances of gnome-desktop-
> configuration? It looks to me that merging multiple instances is
> quite easy, as you could just merge the lists for each category, and
> the "gnome" field of the extension could simply be ignored. There are
> still issues, such as: how can a service extension replace a package
> with a conflicting one. Maybe that case is too far out of scope.
In my humble opinion, instantiating services twice and merging them
doesn't make sense for a number of services, with gnome being one of
them.  We already have an escape hatch for further packages and
configuration records support extension via inheritance (+ public
accessors).

> That being said, the extensibility of the gnome-desktop-service-type
> is not very much needed, because we can also extend the udev, polkit
> and profile services directly.
That too.

Cheers