Re: wrap-program

[ludo@gnu.org (Ludovic Courtès)]

Federico Beffa <beffa@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’.