Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[gentoo-dev] [RFC] TeX font cache, how to handle it, how to not (aka /var/cache/fonts sandbox violations)

13 views
Skip to first unread message

Alexis Ballier

unread,
Nov 10, 2007, 1:50:08 PM11/10/07
to
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.

signature.asc

Christian Faulhammer

unread,
Nov 12, 2007, 7:00:11 AM11/12/07
to
Alexis Ballier <abal...@gentoo.org>:

> 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 ?

Those ebuilds surely inherit a TeX/LaTeX related eclass, maybe add it
there.



> And of course, am I missing something in my reasoning ?

It looks sane to me.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

signature.asc

Alexis Ballier

unread,
Nov 12, 2007, 2:10:10 PM11/12/07
to
On Mon, 12 Nov 2007 12:57:06 +0100
Christian Faulhammer <op...@gentoo.org> wrote:

> Alexis Ballier <abal...@gentoo.org>:
>
> > 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 ?
>
> Those ebuilds surely inherit a TeX/LaTeX related eclass, maybe add it
> there.

I don't think every such ebuild inherits such an eclass. Most of them
just call latex to generate some documentation.


Alexis.

signature.asc
0 new messages