Many packages have documentation in LaTeX, and latex is being run (often when USE=doc). This may cause a sandbox violation, if a font not yet generated on this particular computer is encountered: latex calls metafont to generate it, and metafont wants to write it to /var/cache/fonts (and its subdirectories). The worst thing is that this bug is unpredictable: if only commonly-used fonts are encountered, they are already in /var/cache/fonts, and everything is OK; on some other computer, the same package can produce a sandbox violation.
There are two methods commonly used to fight against this situation in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The second method is, probably, better. The packages still using addwrite are:
Two of them convertex just recently: app-text/jadetex between 3.13-r1 and 3.13-r2, and dev-tex/listings between 1.3 and 1.4. Good for them.
Most disturbingly, there are a number of packages which (probably) run latex and do neither addwrite nor VARTEXFONTS. An incomplete list of such suspect packages is (for now, I only considered packages not directly related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive and not TeX/LaTeX packages in app-text):
(*) By the way, here a .pdf file is installed using dodoc, and hence will be bzip2ed - not a goog idea
(**) but not later versions
(***) The only place where the USE flag "doc" is used commented out???
(****) USE flag "doc" never used??
These are (potentially) bombs waiting to blow up an unsuspecting user. They should be carefully checked.
By the way, while investigating this question, I found quite a few packages which still depend on virtual/tetex, while, probably, virtual/latex-base would be better (in some of them, the USE flag tetex then should become latex). Some suspects are:
> There are two methods commonly used to fight against this situation > in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The > second method is, probably, better.
Packages should definitely go for the VARTEXFONTS one as I'll probably drop forced global writable /var/cache/fonts at some point in the texmf-update script (not that its a security issue but I really dont like having it like that); if its not world writable and a package needs to build some fonts and isn't run as root (default nowadays?) the addwrite will not allow it to write there afaik and it will fail. Nice you have such a list, please assign a bug to t...@g.o for that and I'll see what I can do to convert them (perhaps adding the maintainers in case they want to know what's up and are willing to help). See: https://bugs.gentoo.org/show_bug.cgi?id=204433 http://groups.google.com/group/linux.gentoo.dev/browse_thread/thread/...
> Most disturbingly, there are a number of packages which (probably) > run latex and do neither addwrite nor VARTEXFONTS. An incomplete list > of such suspect packages is (for now, I only considered packages not > directly related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive > and not TeX/LaTeX packages in app-text): [...] > These are (potentially) bombs waiting to blow up an unsuspecting > user. They should be carefully checked.
Yeah or maybe they dont need any unusual fonts; its probably sane to set VARTEXFONTS regardless. Probably it'd be worth adding a latex eclass that would just contain: VARTEXFONTS=${T}/fonts and inherit it from any package calling latex to avoid code duplication (like e.g. the mono eclass do). What do you think ?
> By the way, while investigating this question, I found quite a few > packages which still depend on virtual/tetex, while, probably, > virtual/latex-base would be better
Yep, it would be cool to kill virtual/tetex because it does not make much sense nowadays. Some might be false positives but please also file a bug for t...@g.o with that list and cc the maintainers to see what can be done.
On Tue, May 13, 2008 at 12:31 AM, Alexis Ballier <aball...@gentoo.org> wrote: > Yeah or maybe they dont need any unusual fonts; its probably sane to > set VARTEXFONTS regardless. Probably it'd be worth adding a latex > eclass that would just contain: > VARTEXFONTS=${T}/fonts > and inherit it from any package calling latex to avoid code duplication > (like e.g. the mono eclass do). > What do you think ?
As long as we can't easily remove eclasses I'd rather we don't make a new one for such trivial needs. Unless I've missed something and they can easily be removed nowadays.
Also, overloading the environment with global variables should be avoided when possible. In that case I'd recommend the VARTEXFONTS variable be passed with the emake command or whatever needs latex in the ebuild.
Denis. -- gentoo-...@lists.gentoo.org mailing list
Alexis Ballier wrote: > > These are (potentially) bombs waiting to blow up an unsuspecting > > user. They should be carefully checked. > Yeah or maybe they dont need any unusual fonts; its probably sane to > set VARTEXFONTS regardless.
If LaTeX has been never used on this particular computer (just installed as a dependency), even cmr10 will lead to sandbox violation.
Andrey -- gentoo-...@lists.gentoo.org mailing list
>>>>> On Mon, 12 May 2008, Andrey Grozin wrote: > There are two methods commonly used to fight against this situation > in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The > second method is, probably, better.
Why? This would mean that all fonts must be regenerated each time the package is built. And it doesn't even help if they are already present in /var/cache/fonts, since the directory is then also ignored for reading.
And Metafont can be quite expensive in computing time. That's why there is a font cache, in the first place. ;-)
Ulrich -- gentoo-...@lists.gentoo.org mailing list
On Mon, May 12, 2008 at 09:23:29PM +0000, Andrey Grozin wrote:
[...]
> Most disturbingly, there are a number of packages which (probably) run > latex and do neither addwrite nor VARTEXFONTS. An incomplete list of such > suspect packages is (for now, I only considered packages not directly > related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive and not > TeX/LaTeX packages in app-text): [...] > media-gfx/sane-backends [...] > What do you think?
sane-backends had font generation disabled, but I changed it to the VARTEXFONTS method for now. Wouldn't it be better to populate this temporary directory with links to existing cached fonts or something like this? I don't know much about latex internals, but computing the fonts always because one _might_ be written sounds like a bad idea.
> There are two methods commonly used to fight against this situation in > ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The second > method is, probably, better. The packages still using addwrite are:
Patrick Kursawe <phosp...@gentoo.org> wrote: > On Mon, May 12, 2008 at 09:23:29PM +0000, Andrey Grozin wrote: > [...] > > Most disturbingly, there are a number of packages which (probably) > > run latex and do neither addwrite nor VARTEXFONTS. An incomplete > > list of such suspect packages is (for now, I only considered > > packages not directly related to TeX/LaTeX, i.e., not in dev-tex or > > dev-texlive and not TeX/LaTeX packages in app-text): > [...] > > media-gfx/sane-backends > [...] > > What do you think?
> sane-backends had font generation disabled, but I changed it to the > VARTEXFONTS method for now. Wouldn't it be better to populate this > temporary directory with links to existing cached fonts or something > like this? I don't know much about latex internals, but computing the > fonts always because one _might_ be written sounds like a bad idea.
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. This should be what you were asking for ;)
Ulrich Mueller <u...@gentoo.org> wrote: > >>>>> On Mon, 12 May 2008, Andrey Grozin wrote:
> > There are two methods commonly used to fight against this situation > > in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The > > second method is, probably, better.
> Why? This would mean that all fonts must be regenerated each time the > package is built. And it doesn't even help if they are already present > in /var/cache/fonts, since the directory is then also ignored for > reading.
Per my other mail its a non issue now ;)
However, if an ebuild needs some fonts not in the font cache or the texmf tree(s) it'll generate it in VARTEXFONTS, and since they're not merged into the filesystem, it will do that each time the package is built.
My opinion is that it is not so important because merging them will cause headaches: - How to detect when some fonts have been generated ? - Should we merge them in src_install so that it's in the package contents ? it'll get removed when the package is gone - In some pkg_ functions so that it doesnt get removed; is this safe for binpkgs ? that'll leave stray files, but that's more or less the point of doing it like that. - Where should we merge them ? hardcoding /var/cache/fonts is a no-no as, even if for now it's forced to be there by texmf-update, it would be a good idea not to do so and allow people to change the location. We can ask for the value with kpsewhich; but is that a good idea to install files in locations based on user defined config files ?
Alexis Ballier <aball...@gentoo.org> writes: > - In some pkg_ functions so that it doesnt get removed; is this safe > for binpkgs ? that'll leave stray files, but that's more or less the > point of doing it like that.
Cache being cache, I'd say that it should be done in the ebuilds installing the fonts in pkg_* functions. I'd say not in src_* because packaging up the cache is not what one wants in almost all cases, you wouldn't want a buggy TeX version creating broken packages when you can avoid that.
> By the way, while investigating this question, I found quite a few > packages which still depend on virtual/tetex, while, probably, > virtual/latex-base would be better (in some of them, the USE flag > tetex then should become latex). Some suspects are:
Not necessarily USE=latex, see bug 196745. virtual/tetex should phase out, I try to work on it here and there, but I appreciate some help, of course.
|
