From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adonay Felipe Nogueira Subject: Re: Application Setup on Trisquel Date: Sun, 12 Nov 2017 12:55:05 -0200 Message-ID: <877euv7diu.fsf@hyperbola.info> References: <1508868738.10767@bluehome.net> <873768nt5e.fsf@gnu.org> <87lgk0rrlx.fsf@kryshen.net> <87lgjxg5it.fsf@gnu.org> <1510123173.8495.16.camel@leela> <87zi7upuy9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDtfG-00025Y-7K for help-guix@gnu.org; Sun, 12 Nov 2017 09:55:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDtfC-0005lb-WE for help-guix@gnu.org; Sun, 12 Nov 2017 09:55:14 -0500 Received: from relay6-d.mail.gandi.net ([2001:4b98:c:538::198]:52797) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eDtfC-0005kA-MW for help-guix@gnu.org; Sun, 12 Nov 2017 09:55:10 -0500 Received: from adfeno-pc1 (unknown [181.221.145.151]) (Authenticated sender: adfeno@hyperbola.info) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 46F07FB87D for ; Sun, 12 Nov 2017 15:55:07 +0100 (CET) In-Reply-To: <87zi7upuy9.fsf@gmail.com> (Chris Marusich's message of "Thu, 09 Nov 2017 13:05:45 -0800") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: help-guix@gnu.org 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] . [2] . [3] . [4] . Chris Marusich 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] marusich@garuda:~ > $ 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] marusich@garuda:~ > $ 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] marusich@garuda:~ > $ 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] marusich@garuda:~ > $ > --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.