From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: Re: wrap-program Date: Fri, 26 Sep 2014 22:09:15 +0200 Message-ID: References: <87y4tliahf.fsf@gnu.org> <87r3zabohm.fsf@gnu.org> <8738bp16k4.fsf@gnu.org> <87lhpgoxjp.fsf@gnu.org> <87fvfm8m4f.fsf@gnu.org> <87fvfm595n.fsf@gnu.org> <874mw0umtv.fsf_-_@gnu.org> <87tx3yi3ky.fsf@yeeloong.lan> <87egv15w7s.fsf_-_@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXbpU-0001s1-KD for guix-devel@gnu.org; Fri, 26 Sep 2014 16:09:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXbpT-0004sa-A3 for guix-devel@gnu.org; Fri, 26 Sep 2014 16:09:24 -0400 In-Reply-To: <87egv15w7s.fsf_-_@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver 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 =E2=80=98wrap-program=E2=80=99 is a good strategy h= as to be > evaluated on a case-by-case basis. > > In some cases it=E2=80=99s OK, in others (like wmaker), it=E2=80=99s 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=E2=80=99s 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=3D"$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=3D"$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