[tex-k] Re: web2c-7.5.4, tetex-2.99.10-beta -- patches and problem

Thomas Esser te at dbs.uni-hannover.de
Wed Jan 26 22:50:56 CET 2005

Hi Peter,

thanks a lot for your patches, they all look very useful / good to me.

And I am grateful to your comments about the other issues about the setup
/ default configuration. Maybe, this came just in time to change it...

> I think teTeX's kpsetool and kpsetool.man are broken.

I just have this some compatibility with very old versions of teTeX. Some
people might still use them in their scripts. I agree that
  "kpsetool -w" != kpsewhich
but the manpage and the kpsetool help string are currently claiming that
these are the same. This should be improved. Other than this, I don't
see a problem with kpsetool / kpsexpand / kpsepath. They still work:

$ kpsexpand '$TEXMF'

$ kpsepath bib

$ kpsetool -w tex article.sty


I have already discussed the precedence of TEXMFHOME in my earlier
mail. TEXMFCONFIG and TEXMFVAR have to come first. And given the default
of TEXMFCONFIG=TEXMFVAR=TEXMFMAIN, one would cause misunderstandings
by changing the order of TEXMFHOME and TEXMFMAIN. (BUt, read below,
maybe we can change this).

> (b) In the present setup TEXMFVAR=TEXMFCONFIG=TEXMFMAIN. This has several
> consequences:
> The search order is messed up.

I don't know what you mean with messed up. It is certainly deterministic
and it gives ~/texmf the precedence (the highest) that is needed for
proper operation of my tools.

>  	duplicate search (slow down)?

Yes. There was not enough time to implement duplicate elimination. Only
mktexlsr has it. The default configuration lists TEXMFMAIN three times,
but this tree is usually small.

> 	duplicate rebuild of ls-R (just ugly)?


> (c) The tetexdoc document indicates (suggests?) that one could use
> TEXMFVAR=TEXMFCONFIG=TEXMFHOME. There are again duplicates but the search
> order would be different from case (b).

It suggests this as one possible way for users to have their own set of
configuration. If one has a large TEXMFHOME tree, it would propably be
better to set TEXMFVAR / TEXMFCONFIG to some different directory.

> (d) The search order shouldn't be affected by choosing either (b) or (c). I
> don't see a clear solution to that other than requiring that TEXMFVAR and
> TEXMFCONFIG must be different from TEXMFHOME and from all components of
> SYSTEXMF (although TEXMFVAR and TEXMFCONFIG could well be equal).

It would be a problem if e.g. a local sysadmin puts e.g. the koma-script
package into TEXMFMAIN (he should use TEXMFLOCAL). That way, in (b) local
users can't make use of their own version of koma-script in TEXMFHOME.

If the texmf trees are used in the right way, there should not be a
problem with the difference between (b) and (c).

> At the moment I would (in a multiuser environment) strongly argue for
> something like
> 	TEXMFVAR=$HOME/texmf-var
> 	TEXMFCONFIG=$HOME/texmf-config
> or

> plus MT_FEATURES=appendonlydir:varfonts in kpathsea/mktex.cnf such that
> fonts (with sources in SYSTEXMF) are generated in e.g.,
> /var/lib/texfonts, plus TEXMFHOME preceeding TEXMF{LOCAL,MAIN,DIST}.

Well, we have to decide: either texconfig / fmtutil / updmap default to
a global tree used by all users, or we choose user-individual trees.
One thing makes it easier for the administrator, the other makes it
easier for users.

Let us discuss this a little more:

  CON: users have to set variables in order to be able to use my tools
  CON: TEXMFMAIN directory listed multiple times in TEXMF variable
  PRO: "make install" and admin-use of texconfig works by default

default=individual (e.g. TEXMFVAR=~/.texmf-var, TEXMFCONFIG=~/.texmf-config):
  PRO: minimal reduandancy in TEXMF variable (only TEXMFVAR=TEXMFCONFIG)
  PRO: users can use all tools without setting anything
  PRO: since TEXMFVAR/TEXMFCONFIG != TEXMFMAIN, it now would be possible
       to search TEXMFHOME before TEXMFMAIN
  CON: documentation needs to be changed!?
  CON: "make install" has to be fixed
  CON: we need a solution for "global config changes"

I think that if we can eliminate the two last CON points about
default=individual, I might switch to that. Would that make
most people happy?

I can even offer a possible solution for the "make install" issue.
We could use the following in Makefile.in:

	... TEXMFVAR='$$TEXMFMAIN' TEXMFCONFIG='$$TEXMFMAIN' ... $(scriptdir)/fmtutil --all
	... TEXMFVAR='$$TEXMFMAIN' TEXMFCONFIG='$$TEXMFMAIN' ... $(scriptdir)/updmap

That way, the generated files would end up in $TEXMFMAIN.

Ideas for "global config changes" (i.e. admin use of texconfig / fmtutil
/ updmap):
  - tell admin to copy files from his TEXMFVAR/TEXMFCONFIG (hm... BAD)
  - tell admin to set TEXMFVAR/TEXMFCONFIG (well, still not too good)
  - provide wrapper scripts, e.g. texconfig-main which does
    (that would work, but we would hard-wire $TEXMFMAIN)



More information about the tex-k mailing list