Re: [NTG-context] ConTeXt on Debian: The wiki entry

Frank � wrote:

Hans Hagen wrote:

...

Sanjoy Mahajan wrote:

...

A system-wide installation, if done cleanly, would be much easier (as plink pointed out). If you (or 'texexec --make' to generate the formats) ask kpathsea where to put the format files, it'll give you a directory in TEXMFHOME, so a per user install. But how do you ask kpathsea the correct question so that it'll tell you where they should go for a system-wide install?

you can't and i remember asking for such a feature but ... ;

Can you point me to this discussion? I think it doesn't need more as what fmtutil-sys, updmap-sys and texconfig-sys do before calling fmtutil, updmap or texconfig, respectively:

v=`kpsewhich -var-value TEXMFSYSVAR` c=`kpsewhich -var-value TEXMFSYSCONFIG`

TEXMFVAR="$v" TEXMFCONFIG="$c" export TEXMFVAR TEXMFCONFIG

exec updmap ${1+"$@"}

However, it would be probably more elegant and context-like to not have texexec and texexec-sys, but rather a commandline switch - in this case the handling would have to be done in the perl (or ruby?) scripts, which is somewhat trickier.

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) 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, 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). i have no problem with adding a commandline switch which tells texexec where to put the formats although, since your scripts already set variables, the most natural way would be to adapt TEXFORMATS=someplace/web2c/{$engine,} to which texexec already listens, but if some additional switch/feature is needed it can be done 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. I have no idea what texconfig does but i don't think context needs it (i may be wrong).

...

the only way to figure that out is to check all format paths and take the first one that fits; unfortunalty the tetex paths are rather messy so it's hard to predict in what permutation of home, usr, share, sys, opt * local * tex, TeX, teTeX, whatever * texmf, texmflocal, texmf-local, texmf-teTeX, texmf-dis, texmf.local, texmf-whocares * web2c, web2c/engine etc etc a format may end up;

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 parallel this i have texmf-mswin, texmf-linux, texmf-.... with web2c and bin paths 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 -) 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 anyhow, texexec cum suis just expand the texmf var so any setup should work but i rely on other context users to report problems;

where the first three are per-user, the others are system trees. An explanation about installing does not need to know whether, for example, TEXMFLOCAL is called texmf.local or texmf-local or /usr/local/share/texmf. The only problem might be that some users change the order or the trees, but that's not a big problem if we suggest to use the default path.

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)

...

this is further complicated by the fact that kpse has to do some guessing about where it's configuration files are (web2c, etc, home, nowhere),

This is only a problem if people have more than one texmf.cnf - is this actually the case? I don't think I ever heard of that.

i dunno, but since tex distributions tend to be non-downward compatible, i would not be surprised if users at least patch their local one

...

what trees make sense, etc etc; and, yes, some of the paths are hard coded in the binaries, so relocating is tricky ... isn't it magic that tex still runs -)

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); which brings me to the format again ... maybe it makes sense to set TEXFORMATS after all but i can let texexec listen to an extra --key if needed Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------