Bugzilla Bug 196167

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