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

[Eddie Kohler]

Hi 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,!!$TEXMFLOC 
>> AL,!!$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.
>
> Writing into the first writable directory in the TEXMF list would be
> a different concept and this makes the use of TEXMFCONFIG / TEXMFVAR
> pointless. And in your setup, it would always be TEXMFHOME.

Yes, unless the installer didn't have a $HOME/texmf directory.  The  
resulting behavior makes a lot of sense to me.  Packagers or sysadmins  
would compile & install as root, or whatever; root would have no  
$TEXMFHOME; so files meant for sharing would drop into  
TEXMFCONFIG/TEXMFVAR.

> Example how it could go wrong if set up otherwise: Assume that
> some user has a language.dat file in his TEXMFHOME and he sets
> TEXMFCONFIG=$TEXMFCONFIG=$HOME/texmf-texconfig.
>
> If he runs "texconfig hyphen latex" then his modified language.dat gets
> copied into $TEXMFCONFIG and it won't be used from there, because it is
> shadowed by the version in TEXMFHOME. The old version will be used and
> the user will complain about texconfig which does not work.

texconfig could easily warn that the result of 'kpsewhich language.dat'  
does not equal the file that was updated.  In fact, such a warning  
would be super useful anyway.

I understand the annoyance when people complain to you about problems  
with their configuration, but as this thread demonstrates, this will  
happen with the new setup as well!! ;)  Maybe even more.

>> 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
>
> No, not if that "someone" has used TEXMFMAIN for this. In that case,  
> you
> could use his versions for those files where you don't have your own  
> copy.

Exactly: if that "someone" has used TEXMFMAIN for this!  They might  
not!  And the texmf.cnf file suggests that they might not.  In my  
manual, therefore, I'll have to tell people to execute the following  
algorithm:

    if (TEXMFVAR is writable && TEXMFCONFIG is writable)
        /* everything is OK */;
    else {
        if (TEXMFVAR = TEXMFCONFIG = TEXMFHOME)
            /* OK, no need to copy files */;
        else {
            cp -r $TEXMFVAR ~/texmf-var
            cp -r $TEXMFCONFIG ~/texmf-config
        }
        mkdir ~/texmf-var ~/texmf-config
        add environment variable settings as follows:
            TEXMFVAR=$HOME/texmf-var
            TEXMFCONFIG=$HOME/texmf-config
    }

Compare the current algorithm:

    Ensure that $TEXMFHOME is the first thing in $TEXMF
    mkdir ~/texmf

Huge, huge difference.

>> Nits: The definition of SYSTEXMF says, effectively, that TEXMFCONFIG  
>> and
>> TEXMFVAR are per-user.
>
> Don't talk about variables, better think in terms of directories. In  
> the
> default configuration, TEXMFCONFIG = TEXMFVAR = TEXMFMAIN and this is
> listed in SYSTEXMF. If some user reassigns TEXMFCONFIG / TEXMFVAR to
> one of his trees, then it is right that these are not included in  
> SYSTEXMF.

But the comment above TEXMFCONFIG in texmf.cnf suggests that  
TEXMFCONFIG might be set to /usr/share/texmf-config; this directory  
would not be included in SYSTEXMF.

>> not, SYSTEXMF should be updated.  Also, the comment above TEXMF's
>> definition in texk/kpathsea/texmf.cnf is out of date.
>
> Maybe, this should be shortened to the part explaining the braces. It
> might have made sense in the past to explain how to use multiple trees,
> but it is the default for many years. And the default definition is
> already an example, so I don't see the point to repeat it all in the
> comment.

In my recent download the example above TEXMF's definition has  
TEXMFHOME first...

>> thought for a lot of people, to adapt their setups.  I still haven't  
>> quite
>> figured out what I should personally do.
>
> Hm... You could try to detect teTeX-3.0 and then strictly follow its  
> rules:
>   - write generated data (tfm files) into TEXMFVAR
>   - when modifying lcdftools.map, first search the file with kpsewhich,
>     then store the modified file in TEXMFCONFIG
>
> In your manual, tell people to make sure that TEXMFCONFIG / TEXMFVAR
> point to some directory that is writable.

This is certainly more complex; and supporting old & new tetex setups  
with one binary will be fragile, and a huge pain.  (Also, how can I  
detect teTeX-3.0?)

Here are two other proposals.

Proposal A
1. TEXMF's default definition has TEXMFHOME first.
2. updmap, etc. write to the first writable directory in $TEXMF, and  
warn if the updated file is not found first by kpathsea.

Proposal B
1. TEXMF's default definition has TEXMFHOME first.
2. updmap, etc. write to TEXMFVAR/TEXMFCONFIG, UNLESS these directories  
are not writable, in which case they write to TEXMFHOME.  (If that's  
not writable either they barf.)  Again, they warn if the updated file  
is not found first by kpathsea.

Would you be willing to accept patches for either of these proposals?   
Would any similar ideas work for you?

Eddie