l...@gnu.org (Ludovic Courtès) writes: > 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.) >
I'm not sure I understand. Take emacs: the package does not have glib as an input. However, it does have gtk+, which defines schemas in its own tree ".../gtk+-3.10.1/share/glib-2.0/schemas" (and gtk+ is not an input to glib). Therefore, having $XDG_DATA_DIRS in the glib package does not help emacs. The emacs packge needs its own $XDG_DATA_DIRS pointing to the gtk+ schemas. >> >> 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. > Yes, so we should probably define $GTK_EXE_PREFIX in the emacs package with the full path (/gnu/store/...) and not $HOME/.... And given that the gtk+ module is provided by libcanberra, the latter should be an input to emacs as well. > 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. > Since I'm new to glib schemas and gtk modules, I'm trying to understand the correct broadest approach before doing anything. > I think these are mostly GUIs, unlikely to be launched by a service. > I was thinking about windows managers and desktops. Not sure they really need this. >> 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? > I was thinking about a convenient mechanism for providing packages visible to all users of a system. Regards, Fede
