Re: wrap-program

[Federico Beffa <beffa@ieee.org>]

On Fri, Sep 26, 2014 at 10:09 PM, Federico Beffa <beffa@ieee.org> wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> 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.
>

I guess the above just breaks the functional approach to package
management...

So probably in the case of the emacs package we should just add
libcanberra to its inputs and set the full path in the environment
variables.

Fede