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