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

[Eddie Kohler]

Thomas,

I read the documentation, and have browsed a bit through the sources.  I still 
don't really understand what the problem would be with

TEXMF='{$TEXMFHOME,!!$TEXMFCONFIG,!!$TEXMFVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}'

as a default.  Can you explain, please?  How would this cause problems with 
updmap/texconfig/etc.?  If I, as a random user, run updmap, I'd think the 
changed files SHOULD go into my home directory.  If updmap etc. wrote into the 
first writable directory in TEXMF, everything would seem to work out OK.

....

It seems like a bad idea to set TEXMFVAR=$TEXMFHOME and TEXMFCONFIG=$TEXMFHOME. 
  If someone had built a separate TEXMFVAR or TEXMFCONFIG, then I'd need to copy 
the entire contents of that tree into TEXMFHOME; it would become unclear what I 
had changed.  I'm happy with using all the prebuilt formats, I just want to 
install my own fonts.

Some particularly bad problems may come from packagers who set 
TEXMFMAIN=TEXMFDIST=/usr/share/texmf (no separate dist tree).  In this case, and 
with the default TEXMFVAR=$TEXMFMAIN TEXMFCONFIG=$TEXMFCONFIG, *ALL* system 
files will override user files, not just formats and so forth.  This should 
definitely be discouraged.

Anyway, the basic principle of "user files override system files, always" is far 
simpler to understand...

Nits: The definition of SYSTEXMF says, effectively, that TEXMFCONFIG and 
TEXMFVAR are per-user.  If so, how are they different from TEXMFHOME?  If not, 
SYSTEXMF should be updated.  Also, the comment above TEXMF's definition in 
texk/kpathsea/texmf.cnf is out of date.

....

I appreciate that a lot of thought has gone into this, so thanks for taking the 
time to reply.  It's just that this change is going to require a lot of thought 
for a lot of people, to adapt their setups.  I still haven't quite figured out 
what I should personally do.

If you have lcdf-typetools installed, I'd appreciate it if you read otftotfm's 
manual page section on Automatic Mode.  This, for instance, will clearly have to 
change, but I don't know how.

Eddie


Thomas Esser wrote:
>>>I'd like to stress again that the system trees must under no circumstances
>>>shadow files in TEXMFHOME.
> 
> 
> Trees like TEXMFLOCAL and TEXMFDIST have a lower precedence than
> TEXMFHOME, that's no question.
> 
> The trees with a higher precedence than TEXMFHOME are to be used for
> pool files, generated map files, format files etc. If people have files
> like this in their TEXMFHOME, they should set TEXMFVAR=$TEXMFHOME and
> TEXMFCONFIG=$TEXMFHOME. Then, the other trees will no longer shadow the
> user's files, because these settings give ~/texmf the highest possible
> precedence (via TEXMFCONFIG). That way, these people can even use
> texconfig / fmtutil / updmap.
> 
> Giving TEXMFCONFIG and TEXMFVAR the highest precedence is the only way
> to ensure that texconfig / fmtutil / updmap don't write files that are
> shadowed by other files. 
> 
> Section 2.2 of TETEXDOC has a short discription about the new concept
> of teTeX's predefined texmf trees. Not every tree is ment for all kind
> of data. Section 4.4 explains the concept of the "write pointers"
> TEXMFCONFIG and TEXMFVAR.
> 
> The main reason to make this rearrangement and to enforce a little
> structure about what goes into which texmf tree comes from the
> fact that texconfig / fmtutil / updmap no longer edit files "in
> place". E.g. if you use "texconfig hyphen latex" then the language.dat
> files is no longer edited where it was found (except that it already
> exists in TEXMFCONFIG/tex/generic/config), but the modified copy is
> stored in TEXMFCONFIG/tex/generic/config. It was a design goal to make
> the directories configurable where my tools write their data to and to
> make it all *explicit* (e.g. the old updmap has stored the map files in
> the same tree where the updmap.cfg file was found. Sounds nice and right,
> but you cannot avoid that updmap writes into TEXMFDIST this way).
> 
> So, I can only assure that I have spend days (really days, not hours) to
> come to this setup. I won't change it. All I could accept are suggestions
> for better documentation.
> 
> Thomas