Re: texconfig action and site-wide changes
On Tue, 8 Feb 2005, George N. White III wrote: > On Tue, 8 Feb 2005, Thomas Esser wrote: > > > > Did you notice that the table of contents of the INSTALL file is > > > still: > > > > Yes, I noticed it when I looked it up today. Unfortunately, I did > > not notice it before the release. :-( > > Nor any of the testers! Microsoft has the advantage that they can > hire someone who has never used a product they have lots of testers actually _paying_ for it (called "users"). > and ask them to try installing it during testing. SCNR, Regards, Hartmut
Re: texconfig action and site-wide changes
On Feb 8, 2005, at 2:08 PM, Thomas Esser wrote: Did you notice that the table of contents of the INSTALL file is still: Yes, I noticed it when I looked it up today. Unfortunately, I did not notice it before the release. :-( Thomas While we're all belatedly proofreading the INSTALL file: I've just noticed that, in section 3, you probably want an extra line in the standard directory layout: $HOME/texmf % user tree for added fonts and macros (since this seems to be present by default in texmf.cnf). -- Dave
Re: texconfig action and site-wide changes
On Tue, 8 Feb 2005, Thomas Esser wrote: Did you notice that the table of contents of the INSTALL file is still: Yes, I noticed it when I looked it up today. Unfortunately, I did not notice it before the release. :-( Nor any of the testers! Microsoft has the advantage that they can hire someone who has never used a product and ask them to try installing it during testing. TeTeX testers tend to be experienced so most probably didn't bother reading INSTALL. It would be nice to get a few people who are new to TeX involved in testing. -- George N. White III <[EMAIL PROTECTED]>
Re: texconfig action and site-wide changes
On Tue, 8 Feb 2005, Thomas Esser wrote: What would help is some tools to check for duplicates across all the texmf trees so at least you can more easily determine when things in $TEXMFHOME or $TEXMFLOCAL have become older than versions in updated system trees. Such as the one mentioned in Appendix G of the INSTALL document? = G) scanning texmf trees for duplicates Yes, although it would help to put a separator between the 'ls -l' output and the md5sum, e.g.: $info =~ s/ ([^ ]+$)/$md $1/; -- George N. White III <[EMAIL PROTECTED]>
Re: texconfig action and site-wide changes
> Did you notice that the table of contents of the INSTALL file is still: Yes, I noticed it when I looked it up today. Unfortunately, I did not notice it before the release. :-( Thomas
Re: texconfig action and site-wide changes
Thomas Esser <[EMAIL PROTECTED]> schrieb: >> What would help is some tools to check for duplicates across all the >> texmf trees so at least you can more easily determine when things in >> $TEXMFHOME or $TEXMFLOCAL have become older than versions in updated >> system trees. > > Such as the one mentioned in Appendix G of the INSTALL document? > > > = > G) scanning texmf trees for duplicates > > = > ... Did you notice that the table of contents of the INSTALL file is still: , | [...] | 7) final configuration steps | A) appendix: notes on some platforms | B) appendix: note on moving the binaries around | C) appendix: note on updating a single applications | D) appendix: recreating format files | | ` appendices E to G are not mentioned. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texconfig action and site-wide changes
> What would help is some tools to check for duplicates across all the > texmf trees so at least you can more easily determine when things in > $TEXMFHOME or $TEXMFLOCAL have become older than versions in updated > system trees. Such as the one mentioned in Appendix G of the INSTALL document? = G) scanning texmf trees for duplicates = ... :-) Thomas
Re: texconfig action and site-wide changes
On Tue, 8 Feb 2005, Thomas Esser wrote: > > 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). > > Right. > > > This seems to have the (probably unwanted effect) that the user is thus > > cut-off from site-wide changes. > > The same is true if some user puts a custom copy of koma-script into > his $TEXMFHOME. > > > 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 > > Well, this sounds like a complicated solution (different config files > would need different kind of updates) with a questionable effect. What would help is some tools to check for duplicates across all the texmf trees so at least you can more easily determine when things in $TEXMFHOME or $TEXMFLOCAL have become older than versions in updated system trees. -- George White <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia B3Z 2G6
Re: texconfig action and site-wide changes
Hi Frank, > 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.] That is wrong, just try texconfig-sys formats change some bits in the config file (->goes via "fmtutil --edit" to TEXMFSYSCONFIG) and the changed/added formats to via "fmtutil --byfmt" to TEXMFSYSVAR). The environment manipulation done in texconfig-sys has of course not only some effect on the texconfig script that it calls, but also to all other subprocesses. > 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). Right. > This seems to have the (probably unwanted effect) that the user is thus > cut-off from site-wide changes. The same is true if some user puts a custom copy of koma-script into his $TEXMFHOME. > 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 Well, this sounds like a complicated solution (different config files would need different kind of updates) with a questionable effect. Thomas
texconfig action and site-wide changes
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
