bug#48796: Guix on Debian 11 - Cant run or find applications from Guix in Desktop Menus

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

Am Montag, dem 02.05.2022 um 14:49 +0200 schrieb Giovanni Biscuolo:
> Hi Liliana Marie,
Hi Giovanni,

sorry for the late reply.  It seems my slowness caused you to
investigate things on your own, which might have prompted some wrong
conclusions.

> I just think that if Guix (the package manager) cannot automate
> desktop integration on all foreign distros then it should be stated
> in the manual, possibly explaining why and pointing users to the
> foreign distro documentation.
Fair point and I agree (and even submitted a documentation patch once
already), but this problem hits a great many applications and can not
easily be described in all of its failure modes.

> To add a little bit of context (and highlight it's not an issue just
> for Guix as a package manager) I found this bug reports interesting:
> 
> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927907
> flatpak directories not added to XDG_DATA_DIRS on Plasma + Wayland
> (still open, last update 2022-04-16)
> 
> 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931776
> snapd: Installed snaps do not appear in desktop launcher in Debian
> buster. (still open, last update 2022-04-22)
> 
> 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647427
> XDG_DATA_DIRS not set when using openbox-gnome-session
> (resolved on 2013-07-23)
> 
This seems to be a rather Debian-specific issue then.  Note that Ubuntu
Focal Fossa (and probably later Ubuntus) don't experience these issues
because Ubuntu worked around them so that they can ship snaps by
default.  If I wanted to look at this more closely, it'd make sense
then to look at the difference between a basic Debian installation and
a basic Ubuntu installation and check what they do differently w.r.t.
flatpak and snap.

> > > > It even set XDG_DATA_DIRS, which should allow integration with
> > > > the GNOME Shell and other graphical dashboards.
> > > 
> > > No: this does not work, for three reasons:
> > > 
> > > 1. AFAIU "/etc/profile.d/guix.sh" or "~/.profile" are not
> > > sourced/executed in a graphical session (graphical shell?), we
> > > need to ~/.xsessionrc to configure that environment: am I wrong?
> > Depends on your setup.  Some systemd setups don't source it,
> 
> So it depends on the /default/ systemd setup of the foreign distro,
> Debian 11 in this case, because I did not customize it: please do you
> know where I should check for the systemd specific documentation on
> "xdg related stuff"?
There are two things you need to look up.  First, how to modify
environment variables systemd services, and second which service is
actually the one launching your session.  Once you have both, you can
add an override, that starts it with your environment variables.  I'm
not sure if you can tell systemd to "please source my ~/.profile.sh or
similar" easily, but that'd also be an option.

> makes me wonder what (and why) is the differenxe betweeen a Gnome
> Session and an LXDE one: shouldn't the setup be standard? It's the
> systemd specific way to setup an xsession?
What do you mean by standard?  The standard way of spawning a process
in Unix is fork() followed by exec().  All the shell interpreting in
between if you're using a bash-based flow is merely convenience.
> 

> > but note that you can work around that by editing the offending
> > file.
> 
> Please can you point me to the offending file?
I don't sit on your computer and know too little about your setup to do
so.  You can try various debugging techniques to find out which files
affect your environment variables in a graphical session.

> > More importantly...
> > 
> > > 2. XDG_DATA_DIRS gets someway hard reset by "something" to this
> > > value:
> > > 
> > > XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib
> > > /men
> > > u-
> > > xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-
> > > xdg/
> > I would investigate what actually "resets" this.  If it survives
> > XDG_DATA_DIRS=blah $SHELL, then it's in the stuff your shell
> > sources.
> 
> Actually if I give that command in a terminal I get
> "XDG_DATA_DIRS=blah", but I'm pretty sure there is nothing in the
> stuff of my shell sources that resets XDG_DATA_DIRS
Great.  This means there is actually no resetting at all, your code to
set XDG_DATA_DIRS simply isn't evaluated at all and thus the variable
retains its default value, which is probably set somewhere internal to
systemd or the desktop manager.

> > If it doesn't, then you probably just experience (1).
> 
> Yes: there is something in the default systemd/xsession configuration
> of Debian 11 that resets XDG_DATA_DIR.
No, there isn't.  It not being set doesn't mean that something's
resetting it, it can also mean the code to set it is not run.  Since we
spawned a new shell and found the value unchanged, that is exactly
what's happening.

> Please is there some user with a default Debian 11 xsession
> configuration that can try to reproduce this?
> 
> Am I the only one to experience this XDG_DATA_DIR reset issue?
While I haven't experienced this with XDG_DATA_DIRS in particular, I
know the issue itself.  However, I'm not sure if I'm getting across
what's behind it.

As noted above, the issue appears to be more or less specific to
Debian, as other distros tackle related problems w.r.t. flatpak and
snap and those solutions work for Guix too.
> > 

> 1. is that also a cross-distro standard?
Probably not to the extent you're hoping.  I'd hazard a guess that
every window manager more or less rolls their own implementation, which
basically boils down to watching for changes in a certain directory.

> 2. why "xdg-desktop-menu forceupdate" does not work for user
> installed *.desktop menus?
Probably because your environment variables are borked.

> 3. is there any other CLI that allows users to uptate their graphical
> menus after having "manually installed" (write the right file in the
> right folder) a *.desktop file?
Not afaik.

> > > [...]
> > > The main point of this workaround is that I configure
> > > XDG_DATA_HOME, described in the specifications:
> > And that is evil.
> 
> Please can you expand what do you mean with "evil"?
I don't need to, you already found out yourself.

> [...]
> Reading the above it seems perfectly legit to customize XDG_DATA_HOME
> pointing that variable to any user directory I need to add custom
> GUIX menu entries... and I let handle that menu entries to my guix
> profile: do I miss something?
You already found out, but to repeat: yes.

> Should I also customize $XDG_CONFIG_HOME to point to a specific
> directory different from $HOME/.config?
No, unless you know what you're doing and/or are testing an application
that should not write to your actual configuration files.

> > 
> > > [...]
> > > Anyway to make the new installed *.desktop files appear in the
> > > menu, I have to logout and login again: I've still not found a
> > > command (or configuration) to update the menu, "xdg-desktop-menu
> > > forceupdate" does not work.
> > Should it?  It might only honor XDG_DATA_DIRS and ignore
> > XDG_DATA_HOME by accident.
> 
> AFAIU xdg-desktop-menu is supposed to also update user menus
As per the XDG spec, XDG_DATA_DIRS is a preference-ordered PATH
consisting of directories to search for XDG_DATA.  XDG_DATA_HOME not
being included in it is a violation of the XDG spec.

> > Other than that, restarting your shell (if running on X) might be a
> > more lightweight way of refreshing the menu.
> 
> Restarting the shell means restarting the desktop environment?
> 
> I know how to do it with i3 (reload config) but I don't know hot to
> do it with LXDE (or mate, Gnome3, ecc.)
<M-f2> r RET, or Alt+F2 r Return if you prefer this style of writing
keybindings.  In either case, that's the GNOME binding, but Mate should
have the same.  (Don't know about LXDE.)


Cheers