Application Setup on Trisquel

Application Setup on Trisquel

[Caleb Herbert]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

Questions for Section 2.6.2 Name Service Switch

  * How do I run ncsd on Trisquel?
  * Should I get ncsd from APT or Guix?
  * How do I make sure ncsd is "listening on the /var/run/nscd/socket
socket"?


Questions for Section 2.6.3 X11 Fonts

  * Trisquel does not have xset
  * Should I get xset from APT or Guix?


Setting Environment Variables

The manual instructs users on foreign distros to export environment
variables.  Doing this in the shell makes the changes temporary. 
Where should these changes be made permanent?  (It is bad practice to
put environment variables in .bashrc.)


Integration with Trisquel

Is there a way to make Trisquel's GNOME and its main menu aware of
programs installed with Guix?


When to Use APT

Which of the following should be installed by Guix, and which should
be installed by APT?  Is there a way to install everything with Guix?
 Packages marked with * indicate that APT may be needed for
integration with the foreign system.

mps-youtube
youtube-dl
youtube-dl-gui
mumble
hexchat
gajim
icecat
password-store
git
onionshare
tor*
git-crypt
ghc-pandoc
fcitx
fcitx-configtool
hplip*
redshift
lilypond
noweb
texlive
audacity
stow

Re: Application Setup on Trisquel

[Ludovic Courtès]

Hi Caleb,

"Caleb Herbert" <csh@bluehome.net> skribis:

> Questions for Section 2.6.2 Name Service Switch
>
>   * How do I run ncsd on Trisquel?
>   * Should I get ncsd from APT or Guix?

You should get nscd from Trisquel, in its ‘nscd’ package.  You’ll have
more success asking Trisquel questions on Trisquel fora though.  :-)

>   * How do I make sure ncsd is "listening on the /var/run/nscd/socket
> socket"?

You could run “lsof | grep nscd”, but it’s likely to be the case once
nscd running.

> Questions for Section 2.6.3 X11 Fonts
>
>   * Trisquel does not have xset

It surely has a package for it.

>   * Should I get xset from APT or Guix?

Either way is fine.

> Setting Environment Variables
>
> The manual instructs users on foreign distros to export environment
> variables.  Doing this in the shell makes the changes temporary. 
> Where should these changes be made permanent?  (It is bad practice to
> put environment variables in .bashrc.)

/etc/profile would be the right place.

> Integration with Trisquel
>
> Is there a way to make Trisquel's GNOME and its main menu aware of
> programs installed with Guix?

It should be possible, but I don’t know how.  Anyone?

> When to Use APT
>
> Which of the following should be installed by Guix, and which should
> be installed by APT?  Is there a way to install everything with Guix?
>  Packages marked with * indicate that APT may be needed for
> integration with the foreign system.

In general, you can install everything with Guix.  However, for system
services (nscd, sshd, etc.), you’ll usually want to use apt-get because
that’ll not only install the package but also add the relevant service
startup scripts.

HTH!

Ludo’.

Re: Application Setup on Trisquel

[Caleb Herbert]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Ludovic Courtès <ludo@gnu.org> wrote ..
> Hi Caleb,
>
> "Caleb Herbert" <csh@bluehome.net> skribis:

Sal', Luchjo!

> > The manual instructs users on foreign distros to export environment
> > variables.  Doing this in the shell makes the changes temporary.
> > Where should these changes be made permanent?  (It is bad practice to
> > put environment variables in .bashrc.)
>
> /etc/profile would be the right place.

Should this info be added to the manual?  Following the instructions
as-is leads to lost settings.

Thanks for answering all my questions.

Re: Application Setup on Trisquel

[Caleb Herbert]

[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]

Ludovic Courtès <ludo@gnu.org> wrote ..
> You should get nscd from Trisquel, in its ‘nscd’ package.  You’ll have
> more success asking Trisquel questions on Trisquel fora though.  :-)

Done.

> >   * How do I make sure ncsd is "listening on the /var/run/nscd/socket
> > socket"?
>
> You could run “lsof | grep nscd”, but it’s likely to be the case once
> nscd running.

It seems to be running. :-)

root@leela:~# lsof | grep nscd | grep '\/var\/run\/'
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
/run/user/1000/gvfs
      Output information may be incomplete.
nscd       2691            root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2692       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2693       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2694       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2695       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2697       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2698       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2699       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2700       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket
nscd       2691 2701       root   12u     unix 0xffff8800361d4000
 0t0     404213 /var/run/nscd/socket


> > The manual instructs users on foreign distros to export environment
> > variables.  Doing this in the shell makes the changes temporary.
> > Where should these changes be made permanent?  (It is bad practice to
> > put environment variables in .bashrc.)
>
> /etc/profile would be the right place.

Is this correct?

# echo 'export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale' >>/etc/p
rofile
# echo 'export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"' >>/
etc/profile
# echo 'export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-c
ertificates.crt"' >>/etc/profile
# echo 'export GIT_SSL_CAINFO="$SSL_CERT_FILE"' >>/etc/profile
# echo 'export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-
certificates.crt"' >>/etc/profile
# echo 'source $HOME/.guix-profile/etc/profile' >>/etc/profile

Re: Application Setup on Trisquel

[Caleb Herbert]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

> > > The manual instructs users on foreign distros to export environment
> > > variables.  Doing this in the shell makes the changes temporary.
> > > Where should these changes be made permanent?  (It is bad
practice to
> > > put environment variables in .bashrc.)
> >
> > /etc/profile would be the right place.
> 
> Is this correct?
> 
> # echo 'export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale' >>/etc/p
> rofile
> # echo 'export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"' >>/
> etc/profile
> # echo 'export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-c
> ertificates.crt"' >>/etc/profile
> # echo 'export GIT_SSL_CAINFO="$SSL_CERT_FILE"' >>/etc/profile
> # echo 'export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-
> certificates.crt"' >>/etc/profile
> # echo 'source $HOME/.guix-profile/etc/profile' >>/etc/profile

I had to comment those lines in /etc/profile because Trisquel's
display manager would return me to the login screen after entering my
password.

How do I make sure these environment variables are set?

Re: Application Setup on Trisquel

[Mikhail Kryshen]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> Is there a way to make Trisquel's GNOME and its main menu aware of
>> programs installed with Guix?
>
> It should be possible, but I don’t know how.  Anyone?

I don't use Trisquel, but this works for GNOME in Fedora:

  ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix

You might also want to copy or symlink application icons from
~/.guix-profile/share/icons to ~/.local/share/icons
(don't know how to make them visible to GNOME with a single symlink)

-- 
Mikhail

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

Re: Application Setup on Trisquel

[Ludovic Courtès]

"Caleb Herbert" <csh@bluehome.net> skribis:

>> > > The manual instructs users on foreign distros to export environment
>> > > variables.  Doing this in the shell makes the changes temporary.
>> > > Where should these changes be made permanent?  (It is bad
> practice to
>> > > put environment variables in .bashrc.)
>> >
>> > /etc/profile would be the right place.
>> 
>> Is this correct?
>> 
>> # echo 'export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale' >>/etc/p
>> rofile
>> # echo 'export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"' >>/
>> etc/profile
>> # echo 'export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-c
>> ertificates.crt"' >>/etc/profile
>> # echo 'export GIT_SSL_CAINFO="$SSL_CERT_FILE"' >>/etc/profile
>> # echo 'export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-
>> certificates.crt"' >>/etc/profile
>> # echo 'source $HOME/.guix-profile/etc/profile' >>/etc/profile
>
> I had to comment those lines in /etc/profile because Trisquel's
> display manager would return me to the login screen after entering my
> password.

Does ~/.xsession-errors contain hints as to why this happened?

> How do I make sure these environment variables are set?

For the variables themselves, /etc/profile is a good thing, as discussed
above.

I’d probably move “source $HOME/.guix-profile/etc/profile” to
~/.bash_profile, though.

But that’s really a shell question more than a Guix question, I think.

HTH!

Ludo’.

Re: Application Setup on Trisquel

[Ludovic Courtès]

Mikhail Kryshen <mikhail@kryshen.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> Is there a way to make Trisquel's GNOME and its main menu aware of
>>> programs installed with Guix?
>>
>> It should be possible, but I don’t know how.  Anyone?
>
> I don't use Trisquel, but this works for GNOME in Fedora:
>
>   ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix
>
> You might also want to copy or symlink application icons from
> ~/.guix-profile/share/icons to ~/.local/share/icons
> (don't know how to make them visible to GNOME with a single symlink)

Excellent, good to know!

Ludo’.

Re: Application Setup on Trisquel

[Ludovic Courtès]

"Caleb Herbert" <csh@bluehome.net> skribis:

> Ludovic Courtès <ludo@gnu.org> wrote ..
>> Hi Caleb,
>> 
>> "Caleb Herbert" <csh@bluehome.net> skribis:
>
> Sal', Luchjo!
>
>> > The manual instructs users on foreign distros to export environment
>> > variables.  Doing this in the shell makes the changes temporary. 
>> > Where should these changes be made permanent?  (It is bad practice to
>> > put environment variables in .bashrc.)
>> 
>> /etc/profile would be the right place.
>
> Should this info be added to the manual?  Following the instructions
> as-is leads to lost settings.

Would you like to suggest a patch?

The bottom line is that we don’t want to repeat what’s already in the
Bash manual (see
<https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html>),
but we can definitely link to it.

Thanks in advance,
Ludo’.

Re: Application Setup on Trisquel

[Caleb Herbert]

On Thu, 2017-10-26 at 10:52 -0700, Ludovic Courtès wrote:
> "Caleb Herbert" <csh@bluehome.net> skribis:
> > I had to comment those lines in /etc/profile because Trisquel's
> > display manager would return me to the login screen after entering my
> > password.

The errors happened even when I commented the lines.  I think the
whole .profile was just written wrong.  It came from my Slackware
backup.

> Does ~/.xsession-errors contain hints as to why this happened?

I had to delete the entire .profile so my login works.  .xsession-errors
now says nothing interesting, AFAIK:

cal@leela:~$ cat .xsession-errors
        Script for ibus started at run_im.
        Script for auto started at run_im.
        Script for default started at run_im.
        Script for ibus started at run_im.
        Script for auto started at run_im.
        Script for default started at run_im.
        
        
GNOME's Alt+F2 launcher still doesn't know where Emacs is, but the main
menu does.

> I’d probably move “source $HOME/.guix-profile/etc/profile” to
> ~/.bash_profile, though.

That's what I've done.  I think I'm going to keep it this way.

> But that’s really a shell question more than a Guix question, I think.

Sorry.  It's hard to figure some things out sometimes.

> HTH!

What does this mean, anyway?

Re: Application Setup on Trisquel

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 4312 bytes --]

Hi Caleb!

"Caleb Herbert" <csh@bluehome.net> writes:

>> > The manual instructs users on foreign distros to export environment
>> > variables.  Doing this in the shell makes the changes temporary. 
>> > Where should these changes be made permanent?  (It is bad practice to
>> > put environment variables in .bashrc.)
>> 
>> /etc/profile would be the right place.
>
> Should this info be added to the manual?  Following the instructions
> as-is leads to lost settings.

Yes, I think we should add something like that.  However, we should be
careful not to provide overly specific instructions, since the answer to
the question of "How do I permanently set environment variables the
RIGHT way?" depends on many factors, and no single answer will be
correct under all circumstances.

Some (but not all) of the factors it can depend on are what distribution
you're using, what your personal preferences are, what shell you're
using, whether your shell is a "login" shell or not, whether your shell
is a "non-interactive" shell or not, and even the whims of your
graphical desktop environment [1].  The answer to that simple question
is surprisingly complicated.

In any case, we should encourage users to source
$GUIX_PROFILE/etc/profile once.  Perhaps we can add the following
example and suggest that users copy it into an appropriate location,
where it will (hopefully) be sourced only once (maybe suggest
/etc/profile as one possible place to accomplish this?):

--8<---------------cut here---------------start------------->8---
GUIX_PROFILE="$HOME/.guix-profile"
if [[ -f "$GUIX_PROFILE/etc/profile" ]]; then
    source "$GUIX_PROFILE/etc/profile"
fi
--8<---------------cut here---------------end--------------->8---

We've discussed the topic of environment variables on foreign distros
before, but nobody updated update the manual as a result [2].

Caleb, would you like to take a stab at updating the manual?  I think it
would make sense to add this information to the "Binary Installation"
section, probably near where we tell the user to "source ‘etc/profile’
to augment ‘PATH’ and other relevant environment variables.  The process
for submitting a patch is described in the "Submitting Patches" section
of the manual.  I'm sure other new users would appreciate it!

As for your other question - how to make GNOME discover programs
installed via Guix in its menus etc. - I'm afraid that's also
complicated.  The method by which a particular graphical desktop
environment finds installed applications can vary.  In theory, if Guix
installs programs in a way that conforms to the Free Desktop [3]
specifications (in particular, the Desktop Entry Specification), then
Guix-installed applications should be discoverable by desktop
environments which follow those specifications, like GNOME.

However, it's entirely possible that different distributions or desktop
environments may interpret the specifications in slightly different,
mutually incompatible ways [4].  As a result, it might unfortunately be
necessary for users to modify their environment, in ways that are
specific to their situation, in order to teach their environment how to
discover Guix-installed programs.  We also had a prior discussion about
this topic, and it still might be an issue [5].  I'm not sure, since I
don't use Ubuntu too frequently these days.  I use GuixSD instead.

Footnotes: 
[1]  https://bugzilla.gnome.org/show_bug.cgi?id=736660

[2]  https://lists.gnu.org/archive/html/help-guix/2017-05/msg00068.html

[3]  https://wiki.freedesktop.org/www/Specifications/

[4] For example, Ubuntu seems to require .desktop files to have their
executable bit set, but the Desktop Entry Specification does not require
this, so if Guix installs a .desktop file in the right place, but its
executable bit happens to not be set, Ubuntu might not display it.  One
can imagine that maybe, some other distribution might some day declare
that all .desktop files should NOT be executable, which would make it
difficult to satisfy both distros' requirements.  For details, see here:
https://wiki.ubuntu.com/SecurityTeam/Policies#Execute-Permission_Bit_Required

[5]  https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00104.html

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Application Setup on Trisquel

[Caleb Herbert]

On Thu, 2017-10-26 at 10:53 -0700, Ludovic Courtès wrote:
> Mikhail Kryshen <mikhail@kryshen.net> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >>> Is there a way to make Trisquel's GNOME and its main menu aware of
> >>> programs installed with Guix?
> >>
> >> It should be possible, but I don’t know how.  Anyone?
> >
> > I don't use Trisquel, but this works for GNOME in Fedora:
> >
> >   ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix
> >
> > You might also want to copy or symlink application icons from
> > ~/.guix-profile/share/icons to ~/.local/share/icons
> > (don't know how to make them visible to GNOME with a single symlink)

The first symlink works.  The second does not.  Also, I have my own
icons in ~/.local/share/icons, so I'm not sure if I could use Stow to
manage all those symlinks.  Could I?

Re: Application Setup on Trisquel

[Mark H Weaver]

"Caleb Herbert" <csh@bluehome.net> writes:
>   * Trisquel does not have xset

On Debian-derived systems, 'xset' is part of the
'x11-xserver-utils' package.  I found this by visiting:

  https://packages.debian.org/file:xset

or see the "Search the contents of packages" section of
https://packages.debian.org/

     Mark

Re: Application Setup on Trisquel

[Caleb Herbert]

On Thu, 2017-10-26 at 10:53 -0700, Ludovic Courtès wrote:
> Mikhail Kryshen <mikhail@kryshen.net> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >>> Is there a way to make Trisquel's GNOME and its main menu aware of
> >>> programs installed with Guix?
> >>
> >> It should be possible, but I don’t know how.  Anyone?
> >
> > I don't use Trisquel, but this works for GNOME in Fedora:
> >
> >   ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix
> >
> > You might also want to copy or symlink application icons from
> > ~/.guix-profile/share/icons to ~/.local/share/icons

I have a better way.  This did not work for me on Trisquel.

My experience: Apps appeared in the main menu, but GNOME was not aware
of them.  Icons were missing, Emacs would never show up in "Open With",
and I couldn't launch Mumble from Run Application (Alt+F2).

Solution:
https://trisquel.info/en/forum/guix-trisquel#comment-122789
(Thanks, ADFENO!)

GNOME sees apps and icons now!

Remaining hurdles:
      * Buttons don't show up, themes don't match:
        https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png
      * Fcitx Mozc input method for Japanese does not work in Guix apps

Re: Application Setup on Trisquel

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 6207 bytes --]

Caleb Herbert <csh@bluehome.net> writes:

> On Thu, 2017-10-26 at 10:53 -0700, Ludovic Courtès wrote:
>> Mikhail Kryshen <mikhail@kryshen.net> skribis:
>> 
>> > Ludovic Courtès <ludo@gnu.org> writes:
>> >
>> >>> Is there a way to make Trisquel's GNOME and its main menu aware of
>> >>> programs installed with Guix?
>> >>
>> >> It should be possible, but I don’t know how.  Anyone?
>> >
>> > I don't use Trisquel, but this works for GNOME in Fedora:
>> >
>> >   ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix
>> >
>> > You might also want to copy or symlink application icons from
>> > ~/.guix-profile/share/icons to ~/.local/share/icons
>
> I have a better way.  This did not work for me on Trisquel.
>
> My experience: Apps appeared in the main menu, but GNOME was not aware
> of them.  Icons were missing, Emacs would never show up in "Open With",
> and I couldn't launch Mumble from Run Application (Alt+F2).
>
> Solution:
> https://trisquel.info/en/forum/guix-trisquel#comment-122789
> (Thanks, ADFENO!)
>
> GNOME sees apps and icons now!

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.

> Remaining hurdles:
>       * Buttons don't show up, themes don't match:
>         https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png

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

>       * Fcitx Mozc input method for Japanese does not work in Guix apps

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.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Application Setup on Trisquel

[Caleb Herbert]

On Thu, 2017-11-09 at 13:05 -0800, Chris Marusich wrote:
> 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?

I don't know how to solve it, but I tried what was done in that post,
and it seemed to help.

        env -u XDG_DATA_DIRS icecat &
        env -u XDG_DATA_DIRS youtube-dl-gui &
        
IceCat looked much better:
http://bluehome.net/csh/screenshot/2017/11/10/icecatprofile 
http://bluehome.net/csh/screenshot/2017/11/10/icecatwindow

youtube-dlG, however, looked the same:
http://bluehome.net/csh/screenshot/2017/11/10/youtubedlgui

> "/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?

You'd have to ask ADFENO.  I didn't think too much about the changes I
made to my system.  I just looked at his instructions, determined if
they were harmless, and followed them.

> 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 agree.  I'm just a luser.  I don't have a spare system to do
experiments on, and I don't want to be doing experiments on my only
device.

> > Remaining hurdles:
> >       * Buttons don't show up, themes don't match:
> >         https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png
> 
> Could this be the same issue that I saw with emacs?

Yes.

> >       * Fcitx Mozc input method for Japanese does not work in Guix apps
> 
> 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)?  

No.  I tried doing that, and Fcitx wouldn't run properly because it
didn't like the fact that Trisquel had its own ibus running.

> 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?  

Yes, this is what I did.

        sudo apt install fcitx fcitx-mozc

I can type Japanese in Trisquel apps, but not in Guix apps.

Also, Trisquel's Fcitx will let me type Japanese but not any other
language.  Greek is available, but I still get "aoeu" when I switch to
it.

> 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.

I would gladly use Guix's Fcitx, because its Mozc is newer and lets you
type もも  (momo, "peach") to get 🍑 (":peach:").  But, as mentioned
above, it doesn't play nice with Trisquel's ibus.

> FWIW, I have been able to get Japanese input working in GuixSD in all
> apps using ibus and ibus-anthy.

##japanese on Freenode says Anthy is abandoned, so they recommend Fcitx.

Re GuixSD, I should take the hard drive out of my old laptop and install
GuixSD to try it out.

Re: Application Setup on Trisquel

[Adonay Felipe Nogueira]

For the case of themes not matching and buttoms not showing up, perhaps
one can try the suggestion I made to that same thread ([1]).

[1] <https://listas.trisquel.info/pipermail/trisquel-users/2017-November/082712.html>.

Caleb Herbert <csh@bluehome.net> writes:

> I have a better way.  This did not work for me on Trisquel.
>
> My experience: Apps appeared in the main menu, but GNOME was not aware
> of them.  Icons were missing, Emacs would never show up in "Open With",
> and I couldn't launch Mumble from Run Application (Alt+F2).
>
> Solution:
> https://trisquel.info/en/forum/guix-trisquel#comment-122789
> (Thanks, ADFENO!)
>
> GNOME sees apps and icons now!
>
> Remaining hurdles:
>       * Buttons don't show up, themes don't match:
>         https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png
>       * Fcitx Mozc input method for Japanese does not work in Guix apps

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

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 <cmmarusich@gmail.com> 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.

Re: Application Setup on Trisquel

[Adonay Felipe Nogueira]

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 <adfeno@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>.