expected result: emerging/unmerging fonts should update the font cache correctly. actual result: after emerging fonts, fonts is scanned again and stored into $HOME if non-root users run a app that access the fonts. reproduce steps: cleanup: # emerge --unmerge some-font-package # cd /usr/share/fonts # rm -f fonts.cache-1 # fc-cache reproduce: # emerge some-font-package # grep some-font-package /usr/share/fonts/ fonts.cache-1 (not found) # su non-rootuser $ strace app-that-use-font (u can tell from the output, it's accessing the fonts file slowly, and generate a cache in $HOME) # cd /usr/share/fonts # fc-cache # grep some-font-package /usr/share/fonts/ fonts.cache-1 (found, no problem now)
The eclass assumes that the user/root does not run fc-cache at all, it may seriously unfluence it's functioning. The cache file is per font, and not the one in the fonts root dir. The cache file should be in the 'equery f <font package>' output.
you're right about the per font equery f arphicfonts [ Searching for packages matching arphicfonts... ] * Contents of media-fonts/arphicfonts-0.1-r2: .... /usr/share/fonts/arphicfonts/fonts.cache-1 but this cache file is useless if /usr/share/fonts/fonts.cache-1 isn't updated by root. the eclass should update the system wide font cache, shouldn't it? this is something like env-update
No, the cache file in /usr/share/fonts is just the cache for that dir alone (and therefore empty). The eclass is correct as far as I can see, but not bulletproof to people experimenting with running fc-cache themselves (which is not reccomendable in our setup). Anyway, the cache system has changed in the latest release (2.4.x) and the eclass has been updated accordingly. The possible problem here only applies to older releases.
