bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

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

Am Montag, dem 05.02.2024 um 16:08 +0000 schrieb Dariqq:
> 
> On 04.02.24 20:26, Liliana Marie Prikler wrote:
> 
> > Yes, it seems Maxim and I have conflicting goals.  Maxim wants to
> > avoid "abusing" gnome-shell-assets whereas I want to avoid
> > propagation, as it pollutes profiles.  Perhaps Maxim and I can
> > agree on how to interpret gnome-shell-assets, as IIUC even with
> > packages that aren't "pure data" only the data portion of it ought
> > to be relevant, no?
> > 
> > We should do so especially because the newly propagated variables
> > are anyhow propagated by gnome-desktop-service, which could
> > constitute weird behaviour all around.
> > 
> > Cheers
> 
> What would you think of the wrap-program solution which would avoid 
> propagating pacakges?
> 
> I currently have something like
> 
> #+BEGIN_SRC scheme
> (add-after 'install 'wrap-gdm
>              (lambda* (#:key inputs outputs #:allow-other-keys)
>                (wrap-program (string-append #$output "/bin/gdm")
>                  `("XDG_DATA_DIRS" ":" prefix
>                    #$(map (lambda (input)
>                            (file-append (this-package-input input) 
> "/share"))
>                          '("at-spi2-core"
>                            "dconf"
>                            "gnome-control-center"))))))
> #+END_SRC
> 
> Also this way the assets (adwaita and cantarell) should be kept in
> the gdm-configuration as when I tested this I had a white box as a
> cursor.
That SGTM, but we do need a more descriptive phase name.  The question
is whether we should inline the gnome-shell assets this way as well or
not.

Maxim, WDYT?