An addendum: as was pointed out the default values for $XDG_DATA_HOME
and $XDG_DATA_DIRS are only assumed if these are unset.
Besides, in the short-term solution that suggests appending values to
$XDG_DATA_DIRS to the environment/shell's profile, I emphasize the need
to do it manually.
Solutions such as:
--8<---------------cut here---------------start------------->8---
[Additional value.]:${XDG_DATA_DIRS:+:}${XDG_DATA_DIRS}
--8<---------------cut here---------------end--------------->8---
Or even:
--8<---------------cut here---------------start------------->8---
if [ $XDG_DATA_DIRS ]
then
export XDG_DATA_DIRS="[Additional value.]:$XDG_DATA_DIRS"
else
export XDG_DATA_DIRS="[Additional value.]"
fi
--8<---------------cut here---------------end--------------->8---
... will both lead only to "[Additional value.]" inside $XDG_DATA_DIRS
--- because the Xsession.d scripts that set the foreign distro's value
for $XDG_DATA_DIRS are run *after* the environment/shell's profile is
read and as far as I can tell, before the user logs in the desktop
environemnt.
Adonay Felipe Nogueira <adf...@hyperbola.info> writes:
> 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>.
