Hans Hagen
concerning fmtutil: there was a time that texexec could call fmtutil, but the lack of engine support (as taco explained, it was a trade off for simplifying the fmt suffix but part of the bargain was nog kept) as well as all kind of messy 'aliasing' going on in tex distributions (leading to dropped patterns and fonts)
Uups, what kind of aliasing? Can you point me to a place where this is discussed?
made us decide to drop that; another reason is that distrubutions like texlive more or less assume a'wipe your system clean and install new' policy which is not possible if you have aditional trees, run older binaries with newer trees, etc,
I know that TeXlive has such an approach, but as I understood it this only extends to the TeXlive system itself: TEXMFLOCAL, TEXMFHOME and any other user-added tree should continue to work. Pool files are a problem, but if ConTeXt has found a way to use for example different versions of pdftex and let each one find its correct pool file, I think this feature should be implemented in TeXlive, too.
which is why texmfstart came around: relocating script paths and enc/map paths was done in not downward compaible ways (which in turn is the reason why context ships with all kind of tools to clean up and reorganize trees etc).
Hm, it seems I really need to actually dig into what texmfstart and other ConTeXt scripts do before I can continue. I thought everybody was happy with current TDS, and also that it didn't leave important things unspecified.
Concerning updmap, as Taco explains in another mail, context does not use updmap output; this has a long history:
- context had runtime map loading before updmap was around - we never used the 'huge map files' because it was real slow (this was fixed at some point, hash instead of linear search) - merging map entries in to one big file is dangerous (there can be multiple instances of fonts, same name, different metrics, same longname, different font etc) - we want clean and easy ways to add support for commercial fonts (which is the majority) - pdftex and dvipdfmx were adapted to do run time loading
so, there is no need to spend time on updmap for context.
But maybe other formats could profit from ConTeXt's way to do it, too: These arguments seem to apply to LaTeX and whatever else, too.
I have no idea what texconfig does but i don't think context needs it (i may be wrong).
I never need it... It's just a textmode-menu interface to things like editing language.dat (hyphenation patterns for latex and relatives), calling updmap, changing dvips defaults, etc.
I'm not sure what you mean. The default TEXMF path for teTeX (and I think also for TeXlive) is
TEXMF = {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}
the problem with texmf is that there can be many variants, and there have been in the past; here i now have:
TEXMF={!!$TEXMFPROJECT,!!$TEXMFFONTS,!!$TEXMFLOCAL,!!$TEXMFEXTRA,!!$TEXMFMAIN}
texmfproject : a tree for project related files, these will not be wiped out with an update texmffonts : a safe place for commercial fonts, also not being wiped out (may have older tds structures) texflocal : the place for updates and specific user settings texmfextras : introduced a few years ago in texlive for non free stuff (first dvd productions) texmfmain : on my system a mere copy of the latest tex live, just the whole lot
So you don't use TEXMFVAR and user-specific trees? Anyway, I still fail to see how that's a problem for context updates. The natural approach seems to be - check whether context already exists anywhere except texmfmain (where the update can't go because of the wiping out) - if yes, check whether the directory is writable - if one answer was no, ask the user where to put it.
interesting is that a request for texmfproject and texmffonts on the tex live list was rejected by tetex folks because they didn't want extra paths, but see what extra paths tetex adds -)
The extra paths that teTeX (and TeXlive too) add are paths with a particular role for each. From what you told me so far, I don't see what the difference between TEXMFPROJECT, TEXMFFONTS, TEXMFEXTRA and TEXMFLOCAL is, and why it is a problem for ConTeXt updates that individual admins might add trees.
concerning tex live: i must admit that i only copy the tree and use a much simplified texmf.cnf file which as a side effect makes tex run faster
That's an interesting point, in particular for us Debian people: We have split up texmf.cnf in individual parts (for reasons that don't matter here), and we might be able to provide a minimal texmf.cnf like yours if texlive-latex is not installed, but texlive-context is.
sure, but the fact that the 'real' names change every now and then makes it hard for users to cary a history around without renaming; also, one of the ideas behind tds and web2c was that platforms could share trees, which is what i like: i have one set of trees for running all platforms (so, texmf-local it is here)
That's not so much of a problem in Debian, because the package managment system will respect your changes and always keep texmf-local if you like. But generally I agree that this is suboptimal.
AFAIK only the search path for texmf.cnf is hard-coded, and that can't be avoided. On the other hand, no one ever approached me and requested a relocation: What would you want, and in which cases?
i think that there are a few more paths in there (you sometimes see them in var expansions, but normally they don't hurt) ; life would be easier if texmfcnf was always taken from an env var; actually, i set all important env vars anyway, if only because it isolates tex distrubutions (after all we're talking about a only a few vars than determins all);
I trust you to do it right, but we've had a couple of bogus bugreports from people who set env vars wrongly, or completely forgot they ever had... I'll see that I or Norbert Preining look into this and come back with a more constructive proposal. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)