bug#21842: Brasero fails to start on foreign distros

[iyzsong@member.fsf.org (宋文武)]

Federico Beffa <beffa@ieee.org> writes:

> On Fri, Nov 6, 2015 at 3:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> As Andy notes on IRC, Brasero currently fails to start:
>>
>> --8<---------------cut here---------------start------------->8---
>> $  /gnu/store/dq3817g8w80c9hffbgzspslqjy7szq35-brasero-3.12.1/bin/brasero
>>
>> ** (brasero:21487): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
>>
>> (brasero:21487): GLib-GIO-ERROR **: Settings schema 'org.gnome.brasero.config' is not installed
>>
>> Trace/breakpoint trap (core dumped)
>> --8<---------------cut here---------------end--------------->8---
>>
>> On GuixSD, it starts just fine *if* it is installed in ~/.guix-profile,
>> because XDG_DATA_DIRS and XDG_CONFIG_DIRS are appropriately set.
>>
>> However, on foreign distros, it doesn’t work out of the box.
>>
>> Andy suggests using ‘glib-or-gtk-build-system’ for Brasero, which
>> appears to solve the problem.
>>
>> WDYT?
>
> I think that using the 'glib-or-gtk-build-system' is the right thing
> to do. It will create a wrapper with the correct value of some
> environment variables, enabling the program to find its schema.
Sure, I went ahead and push it.
>
>>
>> Should we add a profile hook similar to ‘gtk-icon-themes’ in (guix
>> profiles) but for schemas?
>
> I do not think so because if a program gets the wrong schema (say, a
> different incompatible version) then it may crash. With the
> 'glib-or-gtk-build-system' it is guaranteed that it will find the
> schema used at build time.
Yes, using the schemas cache built from profile is problematic for
a program, but as long as it was wraped, the profile cache won't be
used.

But the profile cache is required for dconf-editor to be functional,
I'd like to add it.

>
> Speaking of GTK+ applications: I think that removing the generation of
> 'icon-theme.cache' from the 'glib-or-gtk-build-system' was a mistake
> (I may even have suggested this). It is my understanding (see [1, 2])
> that this file is not strictly necessary, however it speeds up things
> and is therefore useful. Having the cache generated by the
> build-system allows one to use the program optimally without having to
> install it into a profile.

Technical right, but since the cache (hicolor) build for the program
only contain it's own icon (eg: evince). For desktop-wide applications
(panel, file managers) this cache is not useful at all.
I guess there won't be much speeds up, need tests to find more detail
though :-)

>
> The icon profile hook is still useful because it allows one to add
> icon themes a posteriori, that is after having build a program
> derivation and without having to rebuild it. The wrapper created by
> 'glib-or-gtk-build-system' still looks in the directories listed in
> XDG_DATA_DIRS (similarly for some other variables). See also the
> discussion at [3].
>
> The reason for removing the phase from the build system was to
> suppress annoying collision warnings, but in my opinion it would be
> better to suppress them in a different way. As long as the profile
> hook is the last derivation being installed in a profile, such
> collisions are harmless and should just be masked.
Yes, remove the phase is an easy way to suppress the warnings for
icon cache. (there still have some programs install the icon cache,
which could be handled per-package IMO.)

We did need to suppress the warnings for the schemas cache.
If just mask the collisions instead of avoid collisions actually
don't have performance issue, I'm ok with it.

>
> Regards,
> Fede
>
> [1] https://developer.gnome.org/gtk3/stable/gtk-update-icon-cache.html
> [2] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
> [3] https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00108.html

I'd like to do some tests to see how the icon cache is used actually.

Thanks!