[Nix-dev] Re: Icon cache problems with GTK apps

Yury G. Kudryashov urkud+nix at ya.ru
Sat Jan 22 22:42:24 CET 2011


Vladimír Čunát wrote:

> 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?
I prefer new buildEnv hooks mechanism but I have no time to write it down. 
The packages that form an env should provide hooks, not the expression that 
calls buildEnv.
> 
> Thanks.
> Vlada





More information about the nix-dev mailing list