[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21842: Brasero fails to start on foreign distros
From: |
Ludovic Courtès |
Subject: |
bug#21842: Brasero fails to start on foreign distros |
Date: |
Fri, 20 Nov 2015 15:58:33 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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’.