Federico Beffa <be...@ieee.org> skribis: > 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
Right, that’s one of the reasons why the ‘glib’ package defines it as its search path (see glib.scm.) > 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" That would be easy and could be defined in /etc/profile on the standalone system. However that would force users to install GTK+ in their profile so that the modules it comes with are found, right? This would be inconvenient. > 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. Yes, this is the preferred solution, I think (and I think it’s this case it’s OK to have these two variables leak in sub-processes, as discussed with Mark.) However, we’d like to factorize the extra phase that does the wrapping, so we don’t repeat it for each and every program. > 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. I think these are mostly GUIs, unlikely to be launched by a service. > This could also serve the second purpose of providing initial default > applications (like guix itself!) to all users on "guix on distro" > systems. Hmm what do you mean? Thanks, Ludo’.
