| Summary: | Please use VARTEXFONTS="${T}/fonts" instead of addwrite /var/cache/fonts | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andrey Grozin <grozin> |
| Component: | New packages | Assignee: | TeX project <tex> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | minor | CC: | common-lisp, martin, nerdboy, python |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=223077 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Andrey Grozin
2008-05-13 11:37:04 UTC
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. |