l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver <m...@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. Regards, Fede
