Dear list,
I'm sure many of you have already seen such sandbox violations:
open_wr: /var/cache/fonts/pk/ljfour/public/cm/pk16254.tmp
This is because the program called cannot find a font it wants, thus
compiles it from various other font definitions and puts it
in /var/cache/fonts.
I have seen two ways of handling it:
addwrite /var/cache/fonts
or:
export VARTEXFONTS="${T}/fonts"
(this one overrides the system configuration about the location of the
system font cache)
Here are some rough useless stats:
gentoo-x86 $ grep 'addwrite /var/cache/fonts' * -r | wc -l
54
gentoo-x86 $ grep 'VARTEXFONTS' * -r | wc -l
35
I would try to push for the later and will try to explain why:
- It is possible to set /var/cache/fonts as readonly for users, which
should be the default and be sane. That means if the program is not ran
as root it will fail to write its fonts there. That will result in the
program failing to compile its fonts; at best it will use another one.
Setting this readonly/readwrite can be done easily by texconfig font
ro/rw; which is in fact just a chmod, respectively to 1777 and 755
on /var/cache/fonts
- The font cache dir default can be overriden in the tex distribution
config files; it shouldnt be done, but is still possible.
- Imho ebuilds shouldn't modify the system like that, even if that just
improves the speed for future usage of the font.
- I suspect that using the system cache allows some nasty side
effects, like if a file there refers to a font that has been removed,
it could cause failures.
The "bad" effect of this is that if a font cannot be directly used by
the program and it needs to transform an existing one, it will always
do it; which can be seen as useless cpu usage, but I think it is much
better like that.
I can see that there are still open bugs about such sandbox violations
and lots of ebuilds do the addwrite method. Is there any reason for
that ? I think that any ebuild that calls a program that needs some
fonts managed by a TeX distribution should do something about it
(better safe than sorry).
Is it possible/wanted to do that automagically for every ebuild ? Like
adding it to portage env variables. Or should it be done in each ebuild
that needs it ?
And of course, am I missing something in my reasoning ?
Regards,
Alexis.
|
