Re: Application Setup on Trisquel

[Adonay Felipe Nogueira]

I might have some information that might help understand how
${XDG_DATA_DIRS} interferes in case of GNU Guix in foreign distros.

Reading the XDG Base Directory Specification ([1]):

--8<---------------cut here---------------start------------->8---
[...]

* Basics

The XDG Base Directory Specification is based on the following concepts:

- There is a single base directory relative to which user-specific data
  files should be written. This directory is defined by the environment
  variable $XDG_DATA_HOME

  [...]

- There is a set of preference ordered base directories relative to
  which data files should be searched. This set of directories is
  defined by the environment variable $XDG_DATA_DIRS

  [...]

* Environment variables

$XDG_DATA_HOME defines the base directory relative to which user
specific data files should be stored. If $XDG_DATA_HOME is either not
set or empty, a default equal to $HOME/.local/share should be used

[...]

$XDG_DATA_DIRS defines the preference-ordered set of base directories to
search for data files in addition to the $XDG_DATA_HOME base
directory. The directories in $XDG_DATA_DIRS should be seperated with a
colon ':'.

If $XDG_DATA_DIRS is either not set or empty, a value equal to
/usr/local/share/:/usr/share/ should be used.

[...]

The order of base directories denotes their importance; the first
directory listed is the most important. When the same information is
defined in multiple places the information defined relative to the more
important base directory takes precedent. The base directory defined by
$XDG_DATA_HOME is considered more important than any of the base
directories defined by $XDG_DATA_DIRS. The base directory defined by
$XDG_CONFIG_HOME is considered more important than any of the base
directories defined by $XDG_CONFIG_DIRS

[...]
--8<---------------cut here---------------end--------------->8---

This, as far as I can understand means that $XDG_DATA_HOME (or assumed
default value) is the user defined "data" directory. While
$XDG_DATA_DIRS (or assumed default value) is a preference list that
comes *after* $XDG_DATA_HOME. Inside the list, entries are sorted from
"most preferred" to "last resort".

The combination forms a preference queue, like so:

XDG_DATA_HOME XDG_DATA_DIRS

Where, if there are various values for the same information, the first
appearance takes the lead, and the remaining conflicting values are
discarded. The following quote taken from [1] contributes to this:

--8<---------------cut here---------------start------------->8---
[...]

* Referencing this specification

Other specifications may reference this specification by specifying the
location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies
that:

- Such file should be installed to $datadir/subdir/filename with
  $datadir defaulting to /usr/share.

- A user specific version of the data file may be created in
  $XDG_DATA_HOME/subdir/filename, taking into account the default
  value for $XDG_DATA_HOME if $XDG_DATA_HOME is not set.

- Lookups of the data file should search for ./subdir/filename
  relative to all base directories specified by $XDG_DATA_HOME and
  $XDG_DATA_DIRS . If an environment variable is either not set or
  empty, its default value as defined by this specification should be
  used instead.

[...]

A specification that refers to $XDG_DATA_DIRS or $XDG_CONFIG_DIRS should
define what the behaviour must be when a file is located under multiple
base directories. It could, for example, define that only the file under
the most important base directory should be used or, as another example,
it could define rules for merging the information from the different
files.

[...]
--8<---------------cut here---------------end--------------->8---

Note that from the last paragraph of the quote, one can see that each
project is responsible for dealing with cases where a file *with the
same relative path* is found in various entries in $XDG_DATA_DIRS (note
that we are not talking about $XDG_DATA_HOME here).

For example, suppose I have $XDG_DATA_DIRS *expanded* as follows:

/home/adfeno/.guix-profile/share:/usr/share

We see two entries here, and unfortunatelly, suppose I have two "gnome"
icon themes, one in each entry:

/home/adfeno/.guix-profile/share/icons/gnome
/usr/share/icons/gnome

Both have an "index.theme", so according to the Icon Theme Specification
([2]), the first (in "/home/adfeno/.guix-profile/share") should be used,
as according to [2]:

--8<---------------cut here---------------start------------->8---
[...]

In at least one of the theme directories there must be a file called
index.theme that describes the theme. The first index.theme found while
searching the base directories in order is used. This file describes the
general attributes of the theme. 

[...]
--8<---------------cut here---------------end--------------->8---

Also according to [2], a fallback theme called "hicolor" is assumed in
almost all cases and application authors should install at least a 48x48
icon in the "hicolor" icon theme. Additionaly, application authors can
install a vector version of the icon, and also a theme-specific one (in
another theme, different from "hicolor"). Personally, speaking, if I
were to fiddle with merging a theme to avoid collisions, I would choose
"hicolor" first.

As for the per-application behavior on dealing with multiple data files
of same "relative path" found while reading $XDG_DATA_DIRS, refer to [1]
again where it says this is left to the application to decide.

Now, let's dive in to some other issues, what if the attempt to change
$XDG_DATA_DIRS doesn't take into account it's previous value? And what
if that same person is using GNOME with GSettings/GLib-GIO?

Well, then [3] happens.

Remember that some components of GSettings/GLib-GIO also look for things
inside $XDG_DATA_DIRS ([4]), and that unfortunatelly, some foreign
system distributions have Xsession.d scripts that don't append things to
$XDG_DATA_DIRS (as is the case in [3]). I would say that a long-term
solution would be patching the Xsession.d files of these system
distributions. A short-term one would instruct users to append using
appropriate scripting manually in the shell's profile.

Finally, I'm not a programmer, but I hope this helps clarify the
interaction between $XDG_DATA_DIRS and GNU Guix on foreign system
distributions.

[1] 
<https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>.

[2] 
<https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html>.

[3] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202>.

[4] <https://developer.gnome.org/gio/stable/glib-compile-schemas.html>.

Chris Marusich <address@hidden> writes:

> This sounds very similar to
>
> https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html
>
> in which the interaction between Guix-installed packages (emacs, in my
> case) and the XDG_DATA_DIRS environment variable caused the UI
> (including icons) to display incorrectly.  It would be nice to solve
> this in general for Guix-installed applications on foreign distros.  Do
> you have any ideas about how we can solve it?
>
> The Guix-installed emacs, in particular, has some wrapper scripts:
>
> --8<---------------cut here---------------start------------->8---
> [0] address@hidden:~
> $ cat $(readlink $(which emacs))
> #!/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash
> export 
> XDG_DATA_DIRS="/gnu/store/llwrfx84y7qv00c5y1c6ys24x2i2xh0p-shared-mime-info-1.8/share:/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/share:/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/share:/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
> export 
> GTK_PATH="/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH"
> export 
> GIO_EXTRA_MODULES="/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES"
> exec -a "$0" 
> "/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/emacs-25.3" "$@"
> [0] address@hidden:~
> $ cat /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/emacs-25.3
> #!/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash
> export 
> XDG_DATA_DIRS="/gnu/store/llwrfx84y7qv00c5y1c6ys24x2i2xh0p-shared-mime-info-1.8/share:/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/share:/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/share:/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
> export 
> GTK_PATH="/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH"
> export 
> GIO_EXTRA_MODULES="/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES"
> exec -a "$0" 
> "/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real" 
> "$@"
> [0] address@hidden:~
> $ file 
> /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real
> /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real: 
> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
> interpreter 
> /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/ld-linux-x86-64.so.2,
>  for GNU/Linux 2.6.32, not stripped, with debug_info
> [0] address@hidden:~
> $ 
> --8<---------------cut here---------------end--------------->8---
>
> In particular, note how the two wrapper scripts add (the same) store
> entries to the front of the existing XDG_DATA_DIRS environment
> variable.  I was able to solve my emacs UI problem by removing the
> "/usr/share/" entry from XDG_DATA_DIRS.  You were able to solve your
> problem by adding ${HOME}/.guix-profile/share to the front of XDG_DATA_DIRS
> and adding the foreign distro's XDG_DATA_DIRS (including "/usr/share/"
> to the end).  I feel like these clues are pointing to something, but I'm
> not yet sure what.  Do you have any good ideas?
>
> I think it's fine (although I wish it weren't necessary at all) to
> require users to customize their environment to enable all features of
> Guix-installed applications on a foreign distro (features like properly
> displayed icons, locales, etc.) .  However, asking users to configure
> XDG_DATA_DIRS seems significantly more complicated, due to problems like
> these, and also like bug 26202:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202
>
> I really hope we can figure out a way to get things that rely on
> XDG_DATA_DIRS to work better out of the box.
>
>
> Could this be the same issue that I saw with emacs?  I mentioned this
> above, but here's the link again:
>
> https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html
>
>
> Can you tell us more about your use case?  Are you trying to install
> fcitx etc. via Guix, and then use it to type in Japanese within
> Guix-installed applications (do they use GTK, or something else)?  Or
> did you install fcitx etc. using the foreign distro's package manager
> (e.g., apt-get), and now you are trying to use that IME to type in
> Japanese within Guix-installed apps?  The interaction between an IME and
> its environment is tricky to get right and depends on a lot of factors,
> so I expect it might require a non-trivial amount of work to make it so
> that all Guix-installed apps will correctly make use of an IME that is
> installed and managed by the foreign distro.
>
> FWIW, I have been able to get Japanese input working in GuixSD in all
> apps using ibus and ibus-anthy.  I haven't yet tried to get Japanese
> input working in Guix-installed applications on a foreign distro.