Hi all, [Something completely different, which I found while looking at this:
It seems to me that "texconfig-sys init" should call fmtutil-sys and updmap-sys, too, not fmtutil and updmap plain - I didn't check for texlinks.] I have tried to understand how texconfig works if a user invokes it. As far as I can see, for every configuration file they touch, a copy is generated in TEXMFCONFIG (which is $HOME/.texmf-config by default). This seems to have the (probably unwanted effect) that the user is thus cut-off from site-wide changes. For example, if he changes updmap.cfg because he has an additional font in TEXMFHOME, and afterwards the site administrator adds a second font to TEXMFLOCAL and edits the site-wide updmap.cfg accordingly, this change will not propagate to the user. It seems to me that it would be a good idea to try to implement a scheme for texconfig action in which user changes could override particular site-wide settings, but would still use the settings in site-wide files if possible. I am not sure that this is feasible, but at least I wanted to state my wish. Maybe it could be done along the following lines: If a user changes a configuration file $cfile for the first time, the changed file after "check_out" is not only copied or cat'ed to $TEXMFCONFIG/$relDir/$cfile, but additionally a diff or the change regex is saved in $TEXMFCONFIG/$relDir/$cfile.diff. If the user invokes texconfig again to change the same file, tcmgr will not check out the changed file (i.e. the file kpsewhich would find), but rather first take the file from SYSTEXMF, apply the diff or ReplaceRegex and use the result as the checked out file (it could also check for differences in SYSTEXMF and report those changes to the user). A command "texconfig update" would then be handy to merge site-wide changes into all existing user-specific configuration files. For some configuration files, it might be even easier. texmf.cnf would be an example - just that it cannot be accessed via texconfig AFAIK. But for this file, it would be sufficient to have *only* the lines the user wants changed in his file. libkpathsea will read all available texmf.cnf files, first the user's and then the site-wide, and the first definitions will take precedence. Maybe a similar behavior could be implemented for other configuration files, too. I only fear that it cannot be applied in all cases, because I don't see how one could remove settings completely in this way. Regards, Frank -- Frank K�ster Inst. f. Biochemie der Univ. Z�rich Debian Developer
