[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wrap-program
From: |
Federico Beffa |
Subject: |
Re: wrap-program |
Date: |
Sat, 27 Sep 2014 16:53:41 +0200 |
address@hidden (Ludovic Courtès) writes:
> Federico Beffa <address@hidden> 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
- Re: emacs package, (continued)
- Re: emacs package, Ludovic Courtès, 2014/09/20
- Re: emacs package, Federico Beffa, 2014/09/20
- Re: emacs package, Ludovic Courtès, 2014/09/20
- Re: emacs package, Federico Beffa, 2014/09/20
- GSettings schemas, Ludovic Courtès, 2014/09/22
- Re: GSettings schemas, Mark H Weaver, 2014/09/23
- wrap-program, Ludovic Courtès, 2014/09/24
- Re: wrap-program, Federico Beffa, 2014/09/26
- Re: wrap-program, Federico Beffa, 2014/09/26
- Re: wrap-program, Ludovic Courtès, 2014/09/27
- Re: wrap-program,
Federico Beffa <=
- Re: emacs package, Ludovic Courtès, 2014/09/21
- Re: emacs package, Federico Beffa, 2014/09/21