iyzs...@member.fsf.org (宋文武) skribis: > Federico Beffa <be...@ieee.org> 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’.
