Bugzilla Bug 221921

As discussed in
http://groups.google.com/group/linux.gentoo.dev/browse_thread/thread/bf2e58fe200c0676/b72be3596cd2eb31
and also recently in gentoo-dev, it is better to export
VARTEXFONTS="${T}/fonts" instead of addwriting /var/cache/fonts and its
subdirectories. The latter method will stop working anyway when
/var/cache/fonts will be not world-writable (bug #204433). Please update the
following ebuilds:

app-doc/doxygen
app-office/kletterwizard
app-text/noweb
dev-lisp/cl-mcclim
dev-python/pyopenssl
dev-tex/feynmf
dev-tex/memoir
media-gfx/asymptote
media-libs/t1lib
media-libs/allegro
sci-chemistry/moldy
sci-mathematics/pari
sci-visualization/pyxplot


Reproducible: Always

Steps to Reproduce:

I think that this is a step in the wrong direction, as not using the font cache
is a needless waste of cpu time.

> As discussed in
> http://groups.google.com/group/linux.gentoo.dev/browse_thread/thread/bf2e58fe200c0676/b72be3596cd2eb31
> and also recently in gentoo-dev,

You have opened this bug only 14 hours after your initial posting to -dev, so
you can't really say that the issue was discussed.

media-libs/allegro - tetex stuff was removed a while ago because the docs are
available in other formats and because I didn't like having the addwrites in
there. Just removed the old ebuild which still did this.

(In reply to comment #1)
> > As discussed in
> > http://groups.google.com/group/linux.gentoo.dev/browse_thread/thread/bf2e58fe200c0676/b72be3596cd2eb31
> > and also recently in gentoo-dev,
> 
> You have opened this bug only 14 hours after your initial posting to -dev, so
> you can't really say that the issue was discussed.
This was discussed in November last year, and there was not a single voice
against. Packages are already moving in this direction: app-text/jadetex,
dev-tex/listings made this change recently. I think having a world-writable
/var/cache/fonts is not a good idea, and possibly a security risk.

Alexis, please advise. There's gotta be some way to not bypass the sandbox
without incurring a penalty of wasted cpu cycles.

(In reply to comment #4)
> Alexis, please advise. There's gotta be some way to not bypass the sandbox
> without incurring a penalty of wasted cpu cycles.
> 

Quoting myself:
"""
Normally VARTEXFONTS is for writting fonts one needs to generate;
however, with the usual default configurations files I've seen,
overriding it will make the various apps needing 'em not see the
default font cache directory. I've committed a new tl-core ebuild with
default configuration files that will let it see the old font cache
directory even if VARTEXFONTS is changed, but will of course write to
VARTEXFONTS.
"""


(and btw I'm already on tex@g.o alias ;) )

Done:
sci-chemistry/moldy
sci-mathematics/pari
sci-visualization/pyxplot

can we not simply write into "${D}"/var/cache/fonts if the font is not already
cached?

Then these fonts will be a part of the package files. If the package is
uninstalled, they will be removed. If you produce a binary package, they will
be in the binary tarball. Your package and my package will have different sets
of files.

Surely you WANT fonts to be uninstalled when their package is uninstalled?

(In reply to comment #9)
> Surely you WANT fonts to be uninstalled when their package is uninstalled?
Fonts which we are discussing have *absolutely* nothing to do with any package.
We are discussing *.tfm and *.pk files generated on demand from metafont
sources. Suppose I used LaTeX on articles A,B, and C; and you used it on D and
E. Then I and you have different sets of fonts in out /var/cache/fonts
directories. When I and you emerge the same package foo, different sets of
fonts will be generated when latexing foo docs.
Any files in /var/cache/fonts (or even all of them) may be removed at any
moment (and *are* removed automatically if unused for too long). This will not
affect functionality of LaTeX, only its performance.
To stress the point: an accidental set of fonts generated by metafont when
emerging a package foo is *not* a part of foo, and should not be lumped
together with it in any form.

media-libs/t1lib done.

media-gfx/asymptote done

dev-tex/feynmf done.
I've also changed its install location from texmf to texmf-site.

Since this issue came up in bug 261411:

It is IMHO unnatural to have /var/cache/fonts not world-writable (and sticky)
by default: In the "typical" usage of a TeX system all users should share the
generated fonts. The only case I can think of why you might not want to have
this is if you are afraid of an exploit of a TeX component by maliciously
crafted font data by another user.

Forcing VARTEXFONTS to a different value underruns this principle completely:
In the "typical" situation, the fonts have to be generated with each
installation of the package (with the change of comment #5 there is only
an exception if the fonts have been generated by another user for another
purpose).
Moreover, with the change of comment #5, such bad fonts can still be used to
exploit portage (and thus indirectly to obtain root privileges).

Perhaps it would be reasonable to introduce a global USE flag (or perhaps a
FEATURE in analogy to FEATURES=ccache) which lets the user decide...

(In reply to comment #14)
> Since this issue came up in bug 261411:
> 
> It is IMHO unnatural to have /var/cache/fonts not world-writable (and sticky)
> by default: In the "typical" usage of a TeX system all users should share the
> generated fonts. The only case I can think of why you might not want to have
> this is if you are afraid of an exploit of a TeX component by maliciously
> crafted font data by another user.

... or fill the whole disk

> Perhaps it would be reasonable to introduce a global USE flag (or perhaps a
> FEATURE in analogy to FEATURES=ccache) which lets the user decide...

may I suggest you have a look at the last line of output of texmf-update?

(In reply to comment #15)
>
> may I suggest you have a look at the last line of output of texmf-update?

AFAIK this essentially only changes the permissions of /var/cache/fonts.
However, the ebuilds will then still not use /var/cache/fonts if they override
VARTEXFONTS (depending on the user's settings, the ebuilds might read from
/var/cache/fonts, but they will never write there).

Therefore, the user has no choice unless the choice is made available e.g.
by a USE-Flag from all ebuilds which currently set VARTEXFONTS for
installaion.

If the setting of VARTEXFONTS is done by inheriting some eclass (as was
suggested now in bug 261411) this could easily be implemented by just testing
the corresponding USE-Flag in that eclass.

(In reply to comment #16)
> (In reply to comment #15)
> >
> > may I suggest you have a look at the last line of output of texmf-update?
> 
> AFAIK this essentially only changes the permissions of /var/cache/fonts.

yes

> However, the ebuilds will then still not use /var/cache/fonts if they override
> VARTEXFONTS (depending on the user's settings, the ebuilds might read from
> /var/cache/fonts, but they will never write there).

yes; note that /var/cache/fonts may be changed by editing TeX config files.

> Therefore, the user has no choice unless the choice is made available e.g.
> by a USE-Flag from all ebuilds which currently set VARTEXFONTS for
> installaion.

an useflag is clearly an overkill

> If the setting of VARTEXFONTS is done by inheriting some eclass (as was
> suggested now in bug 261411) this could easily be implemented by just testing
> the corresponding USE-Flag in that eclass.

All this has already been discussed; if you wish fonts cache that are generated
in $T/fonts to be merged back in the global font cache in a pkg_* phase then I
have nothing against it but I still have to see some code.

Note that:
- the font cache isn't necessarily /var/cache/fonts, you have to get it from
kpsewhich
- it is perfectly valid to make it readonly so you must not write there in that
case, even if you're doing it with root privileges if you want to honour user
settings
- pkg_* phases are ran as root so writing to an arbitrary directory
(VARTEXFONTS) that can be overriden by environment variables as root might not
be a so good idea.

In the end I think the current way of setting VARTEXFONTS causing useless font
computations isn't perfect but is the only easy way of doing it sanely.

> if you wish fonts cache that are generated in $T/fonts to be merged back
> in the global font cache in a pkg_* phase

Despite of that this is probably not possible when building/merging binary
packages (I suppose $T is not packaged), I also would not vote for doing this
unless the user agrees (-> use-flag). After all, it might be a huge amount of
exotic fonts which might be just a waste of disk space.
You are right, for most packages it is probably just not worth the discussion.
I was mainly thinking about packages like lilypond where the
TeX-font-generation
takes a considerable amount of time, but looking at the ebuild it appears that
this is unrelated.

Removing kde@ from CC. If there's issues with some package, please open a bug
against it.