Re: wrap-program

[Federico Beffa]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>
>> This 'wrap-program' strategy of setting environment variables before
>> running a program has problems.  In this case, it means that every
>> program run within Emacs will inherit that GSETTINGS_SCHEMA_DIR value.
>>
>> Along the same lines, I've noticed that when running WindowMaker, all of
>> the programs within my X session include a WindowMaker-specific
>> directory at the front of PATH.
>>
>> It would be good to find another solution.
>
> I think whether using ‘wrap-program’ is a good strategy has to be
> evaluated on a case-by-case basis.
>
> In some cases it’s OK, in others (like wmaker), it’s not so nice.
>
> In cases like wmaker, another solution would be to patch the source code
> to execute directly the right binaries, without changing PATH.  The
> downside is that it’s often less convenient to do.

I've looked some more into the problems I've found with the emacs
package:

1. GSettings schemas: More than schemas compilation, the problem is that
the schemas are by default expected to be in $datadir/glib-2.0/schemas
(with $datadir usually being /usr/share).  In spite of this, other
directories can be specified with the help of the environment variable
$XDG_DATA_DIRS.  Since at glib-2.0 compiled time we can't know the path
of future application installations, we may want to define

XDG_DATA_DIRS="$HOME/.guix-profile/share/:$XDG_DATA_DIRS".

If the variable $XDG_DATA_DIRS is not specified, it defaults to
/usr/local/share/:/usr/share/.

https://developer.gnome.org/gio/stable/ch32s06.html
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

2. gtk-3.0 modules: gtk+ looks for modules (like libcanberra.so) in
locations specified by

   a. $GTK_PATH,

   b. $libdir/gtk-3.0/modules, with $libdir being the one specified at
   gtk+-3.0 ./configure time OR $GTK_EXE_PREFIX/lib.

Option a. is inconvenient because that variable is used by both,
gtk+-2.0 and gtk+-3.0, easily leading applications compiled with one
version to find incompatible libraries.

Option b. is more attractive.  Again, at compile time we do not know the
location of future modules installations: Take emacs: it looks in the
gtk+-3.0 directory $libdir/gtk-3.0/modules.  However, it is looking for
a module installed by libcanberra which is not even an input to the
emacs package.  For this reason we should probably define

GTK_EXE_PREFIX="$HOME/.guix-profile"

https://developer.gnome.org/gtk3/3.10/gtk-running.html
Note: the documentation at this site mentions the directory .gtk-3.0 in
$HOME.  However, strace on emacs and the README in the gtk-3.10.1 source
says that this path is no longer used.

Setting the above two variables eliminates both problems (libcanberra
and schemas not found) in the emacs package.  We could probably define
the above variables with 'wrap-program'.  In "guix on distro"
installations this would avoid having guix libraries interfere with a
non guix program.  On the other side, in a guix program launched from
within another guix program, this should be harmless.

We may just want to check that: (i) paths defined in environment
variables are not duplicated by 'wrap-program' definitions (wrap
launched by wrap) and (ii) if the variable is already defined (for "non
guix" reasons), we may want to append the existing value.

The only problem I see right now is if a program is launched by a user
which does not have $HOME/.guix-profile (like a service).  In that case
there could be a default profile.  This could also serve the second
purpose of providing initial default applications (like guix itself!) to
all users on "guix on distro" systems.  And on the gnu system, well,
there are system installed programs.

Regards,
Fede