[Nix-dev] Icon cache problems with GTK apps

[Vladimír Čunát]

Hello,
I've been looking into problems with icons in GTK applications caused
by wrong icon-theme.cache files. Almost every GTK package has these
and they collide in userenv. The systemenv builder ignores the
collisions and builds a new cache (a bit hacky, but works). The
userenv builder complains about collisions (not a big problem) and
leaves one of the cache files in userenv, which prevents GTK icon
mechanism from working correctly (it would work a bit slower without
any cache but it doesn't with bad cache). That for example causes the
xfce menu to have almost no icons for user-installed applications.

IMHO there are two things to be done: (1) preventing the cache files
to get into userenvs and optionally (2) generating a correct cache
when building userenvs.
(1) As the number of affected packages is high and AFAIK there is no
use for the per-package icon caches, I suggest to use some centralized
solution to save the boilerplate. IMO it would be best to modify the
generic builder to delete the cache files by default, perhaps in the
fixup phase. When I examined the scripts, it seemed that this kind of
hacking is rather done in the userenv builder, so I rather modified
the latter (both the nix and nixpkgs version, patch attached). It
seems to work, though I didn't test it much. What do you think?
(2) The systemenv builder is just hacked to regenerate the cache so we
could do the same but I think that we should modularize. I believe
that many other packages could profit from some hook run while
generating the environment (this one would be for GTK). For many
packages that can have plugins it would IMO make sense to collect (by
default) all the plugins in the userenv and use them. For example the
ghc-wrapper could wouldn't have to do this on every ghc run, which
quite can take some time (with cold cache).
What solution would you prefer?

Thanks.
Vlada
-------------- next part --------------
A non-text attachment was scrubbed...
Name: builders.patch
Type: application/octet-stream
Size: 2116 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20110122/b6892624/attachment.obj