From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: Re: wrap-program Date: Sat, 27 Sep 2014 00:17:23 +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]:37346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXdpV-0001rf-OW for guix-devel@gnu.org; Fri, 26 Sep 2014 18:17:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXdpS-0004ye-7G for guix-devel@gnu.org; Fri, 26 Sep 2014 18:17:31 -0400 In-Reply-To: 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 On Fri, Sep 26, 2014 at 10:09 PM, Federico Beffa wrote: > 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 o= f >>> 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 = has 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. > 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