bug#21842: Brasero fails to start on foreign distros

[Ludovic Courtès]

address@hidden (宋文武) skribis:

> Federico Beffa <address@hidden> writes:

[...]

>> 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.

AIUI this (commit 1c40e3b7) fixes the bug, so I’m closing 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.

What’s the conclusion with caches?  We should probably move the
discussion to guix-devel.

Thanks!

Ludo’.