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 15:09:29 -0200 Message-ID: <87wp2v5sqe.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> <877euv7diu.fsf@hyperbola.info> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDvlM-0007SO-3T for help-guix@gnu.org; Sun, 12 Nov 2017 12:09:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDvlH-0001rE-Gt for help-guix@gnu.org; Sun, 12 Nov 2017 12:09:40 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:44471) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eDvlH-0001qu-6y for help-guix@gnu.org; Sun, 12 Nov 2017 12:09:35 -0500 Received: from adfeno-pc1 (unknown [181.221.145.151]) (Authenticated sender: adfeno@hyperbola.info) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 33135A80CE for ; Sun, 12 Nov 2017 18:09:31 +0100 (CET) In-Reply-To: <877euv7diu.fsf@hyperbola.info> (Adonay Felipe Nogueira's message of "Sun, 12 Nov 2017 12:55:05 -0200") 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 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 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] > . > > [2] > . > > [3] . > > [4] .