In texlive-2007 (file /etc/texmf/texmf.d/00texmf.cnf) the variables are set as follows. TEXMFLOCAL = /usr/share/texmf-local TEXMFSYSVAR = /usr/share/texmf-var TEXMFSYSCONFIG = /usr/share/texmf-config In earlier teTeX-3 versions they were set as TEXMFLOCAL = /usr/local/share/texmf TEXMFSYSVAR = /var/lib/texmf TEXMFSYSCONFIG = /var/lib/texmf Debian sets it as TEXMFLOCAL = /usr/local/share/texmf TEXMFSYSVAR = /var/lib/texmf TEXMFSYSCONFIG = /etc/texmf I would prefer the last one. Beside that I needed to add the following (taken from debian) to 00texmf.cnf for makempx to work properly. % Used by makempx to run TeX. We use "etex" because MetaPost is % expecting DVI, and not "tex" because we want first line parsing. TEX = etex
While I'm ok for changing texmflocal, it seems more sane to have it in /usr/local, changing texmf-var would mean changing the eclass, perhaps breaking file ownership because fmtutil will rebuild the formats in the new texmf var etc. I'd say no to this one. And what was the problem with makempx ?
I am using latexmp to typeset LaTeX-labels in metapost. The following minimal-example gives the error: This is MetaPost, Version 0.993 (Web2C 7.5.6) (test.mp (/usr/share/texmf-dist/metapost/latexmp/latexmp.mp) (ltx-test.tmpmakempx: Command failed: tex --parse-first-line --interaction=nonstopmode mpxerr.tex; see mpxerr.log >> ltx-test.tmp >> ltx-test.mpx ! Unable to make mpx file. l.7 latexmp_picture[1]:= btex $x^2$ etex ; Transcript written on test.log. With "TEX = etex" in texmf.cnf it works. -- example: test.mp -- verbatimtex input latexmp; beginfig(1); label(textext("$x^2$"),origin); endfig; end.
Sorry, but there was an error in my posted example. Here is the correct one. -- example: test.mp -- input latexmp; beginfig(1); label(textext("$x^2$"),origin); endfig; end.
From devmanual (http://devmanual.gentoo.org/general-concepts/filesystem/index.html): "/usr/local: Non-portage applications. Ebuilds must not install here." So the answer is clear. :) CONFIG in /etc/ sounds logical, Debian is really strict here. Emacs team was thinking about moving their config directory to /etc, too, but we decided that the change would be very invasive. TeXLive could do it though as it is a real new package.
(In reply to comment #4) > From devmanual > (http://devmanual.gentoo.org/general-concepts/filesystem/index.html): > > "/usr/local: Non-portage applications. Ebuilds must not install here." > > So the answer is clear. :) CONFIG in /etc/ sounds logical, Debian is really > strict here. Emacs team was thinking about moving their config directory to > /etc, too, but we decided that the change would be very invasive. TeXLive > could do it though as it is a real new package. > yep, actually I was thinking about integrating all the changes; this seems more logical for texmfvar to be in /var, as it will be modified by texmf-update. ebuilds dont install to texmflocal, but modifying the variable allows people to install their local files into it rather than /usr/share/texmf-local and +1 also for sysconfig
(In reply to comment #5) > yep, actually I was thinking about integrating all the changes; this seems more > logical for texmfvar to be in /var, as it will be modified by texmf-update. > ebuilds dont install to texmflocal, but modifying the variable allows people to > install their local files into it rather than /usr/share/texmf-local You install the path, any ebuild should leave /usr/local alone, as users are free to mess around with it.
(In reply to comment #6) > You install the path, any ebuild should leave /usr/local alone, as users are > free to mess around with it. I don't understand, it doesn't install anything in texmf-local, it just points kpathsea to the location of the local tree, which is intended to be the user installed files. And users aren't free to mess around with it, having broken libs there already causes some mess as it's in default search paths.
If I remember correctly, the directory is created by one the ebuilds, so I can't tell for sure. If I am wrong, just go on.
Documentation in /usr/share/texmf-doc is not found by texdoc. I copied the following lines from the texmf.cnf contained in the TeX-Live DVD to /etc/texmf.d/00texmf.cnf. % TeX documentation and source files, for use with kpsewhich. % TeX Live has a separate hierarchy with just documentation, texmf-doc, % in addition to the doc files in the other hierarchies. TEXMFDOCDIR = /usr/share/texmf-doc/doc TEXDOCS = .;$TEXMF/doc//;$TEXMFDOCDIR// TEXSOURCES = .;$TEXMF/source// Another path-related question: Shouldn't documentation go to /usr/share/doc?
(In reply to comment #5) > and +1 also for sysconfig I tried this, and it causes a sandbox violation in texlive-core, because the build process tries to run fmtutil: normally /etc/texmf/web2c/fmtutil.cnf isn't on the search path, but is found via the symlink /usr/share/texmf/web2c/fmtutil.cnf. The build system overrides TEXMFMAIN so that /usr/share/texmf is /not/ on the search path anymore, so with the current configuration fmtutil doesn't do anything, but setting TEXMFSYSCONFIG to /etc/texmf allows fmtutil.cnf to be found via the other route. It'll be easy to patch this out (line 76 of the toplevel Makefile.in), but I thought I'd save you the bother of figuring out what's going on.
thanks, so I think sysconfig will remain as it is; I really don't want texlive-core installation to be dependant on config files installed on the system. We do not install anything there and config files that are supposed to be modified are in /etc/texmf/$foo.d, symlinked from the texmf tree and handled by texmf-update raising severity as those changes should really block wide usage of texlive for now.
(In reply to comment #10) > I tried this, and it causes a sandbox violation in texlive-core, *sigh* And now, of course I can't reproduce this. Sorry for the false alarm. I still think patching out the relevant part of the Makefile is a good idea, though, since there may be other potential issues with certain configurations - it also tries to run mktexlsr, texlinks and updmap-sys. (In reply to comment #11) > I really don't want texlive-core installation to be dependant on config > files installed on the system. Agreed.
I've gone a different way, shipping files for /etc/texmf/texmf.d that will generate through texmf-update a texmf.cnf defaults should be much better now, thanks for pointing that. It's not a so good idea to patch texmf.in like mads, because the build system relies on it at some point. I'll push a -r1 when I'll have fixed bug #196246
