bug#59474: Guix Home generated .profile sets XDG_ vars that break GDM+Gnome login on foreign distros

[Andrew Tropin <andrew@trop.in>]

[-- Attachment #1: Type: text/plain, Size: 5754 bytes --]

On 2022-11-21 22:02, Matt Armstrong wrote:

> I am experimenting with Guix Home on Debian Testing, using GDM+Gnome.
> The .profile generated by "guix home reconfigure" broke logging in to
> the Gnome desktop.  The gnome session would die, failing to initialize
> what it considered to be essential things, and return to the login
> screen I could log in to a tty, and was able to undo the new .profile
> and get back to a working system.
>
> The home-configuration.scm I used was generated by "guix home import"
> and was quite simple:
>
> ----------------------------------------------------------------------
> (use-modules (gnu home)
>              (gnu packages)
>              (gnu services)
>              (guix gexp)
>              (gnu home services shells))
>
> (home-environment
>   ;; Below is the list of packages that will show up in your
>   ;; Home profile, under ~/.guix-home/profile.
>   (packages (specifications->packages (list "glibc-locales")))
>
>   ;; Below is the list of Home services.  To search for available
>   ;; services, run 'guix home search KEYWORD' in a terminal.
>   (services
>    (list (service home-bash-service-type
>                   (home-bash-configuration
>                    (aliases '(("ls" . "ls --color=auto")))
>                    (bashrc (list (local-file ".bashrc" "bashrc")))
>                    (bash-logout (list (local-file ".bash_logout"
>                                                   "bash_logout"))))))))
> ----------------------------------------------------------------------
>
> Note: a stock GDM+Gnome setup runs the user's login shell when logging
> in via the GDM display manager, and this shell execs
> gnome-session-binary.  This doesn't necessarily happen with other
> display managers or other desktop environments, so on those systems the
> Guix Home .profile may not even run before the DE is initialized.
> Nearly all of my time debugging this was spent figuring this out!  :-)
>
> The .profile file generated by Guix Home is this:
>
> ----------------------------------------------------------------------
> HOME_ENVIRONMENT=$HOME/.guix-home
> . $HOME_ENVIRONMENT/setup-environment
> $HOME_ENVIRONMENT/on-first-login
> ----------------------------------------------------------------------
>
> The first thing I see is that $HOME/.guix-home/seutp-environment is
> modifying various XDG_ variables incorrectly.  It prepends new values
> without honor the variable's default value if it doesn't happen to be
> set already.
>
> For example, if XDG_DATA_DIRS is not set its default value is
> "/usr/local/share/:/usr/share/".
>
> But .guix-home/setup-environment will instead prepend a value without
> checking, leaving XDG_DATA_DIRS set incorrectly to
> "$HOME/.guix-home/profile/share:" when it should be
> "$HOME/.guix-home/profile/share:/usr/local/share/:/usr/share/".
>
> See this code in setup-environment:
>
> case $XDG_DATA_DIRS in
>   *$HOME_ENVIRONMENT/profile/share*) ;;
>   *) export XDG_DATA_DIRS=$HOME_ENVIRONMENT/profile/share:$XDG_DATA_DIRS ;;
> esac
>
> The correct idiom is this:
>
> XDG_DATA_DIRS=PATH_TO_PREPEND:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}
>
> or
>
> XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:PATH_TO_APPEND
>
> The above is what I see in various Nix and Snap configuration files.
>
> Because I have a few other things installed that modify XDG_DATA_DIRS
> before Guix Home does, Guix Home doesn't break that particular variable.
>
> It did break XDG_CONFIG_DIRS, since Guix Home was setting it to
> "$HOME/.guix-home/profile/etc/xdg:".  I worked around this problem by
> running this code before Guix Home's .profile:
>
>     # Note: when XDG_CONFIG_DIRS is not set Guix home sets
>     # XDG_CONFIG_DIRS="$HOME/.guix-home/profile/etc/xdg:", which removes
>     # the default "/etc/xdg" value.
>     if [[ -z $XDG_CONFIG_DIRS ]]; then
>         XDG_CONFIG_DIRS=/etc/xdg
>     fi
>
>     # Note: when XDG_DATA_DIRS is not set Guix home sets
>     # XDG_DATA_DIRS="$HOME/.guix-home/profile/share:", which removes the
>     # default "/usr/local/share:/usr/share" value.
>     if [[ -z $XDG_DATA_DIRS ]]; then
>         XDG_DATA_DIRS="/usr/local/share:/usr/share"
>     fi
>
> I have other more minor quibbles about how Guix Home handles XDG values:
>
> XDG_STATE_HOME is set to a non-standard value.  In the current XDG Base
> Directory Specification it defaults to "$HOME/.local/state", but Guix
> Home sets it to "$HOME/.local/var/lib".  On a foreign distro this is
> going to cause some disruption when a user switches to Guix Home, or
> switches away.
>
> XDG_LOG_HOME is a non-standard variable.  The spec suggests that logs
> should go in XDG_STATE_HOME.  Why not a establish a GUIX_LOG_HOME
> variable instead?  (if it ever does become a standard XDG variable, its
> default may not be the same one picked by Guix Home, causing the same
> issue as above).
>
> Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to do
> -- it is the job of whatever logs the user in.
>
> XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME are set to their defaults
> unnecessarily.
>
> I modified my personal config by unsetting XDG_STATE_HOME, XDG_LOG_HOME,
> XDG_CACHE_HOME, XDG_CONFIG_HOME, and XDG_DATA_HOME if Guix Home left
> them set to their default values (in the case of XDG_STATE_HOME I unset
> it unconditionally).

XDG_DATA_DIRS behavior seems reasonable, the problem should be reported
to Debian.  The work on STATE_HOME is happenning in a separate thread.
Closing this ticket.  Let us know if you have some other thoughts on the
topic.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]