Re: ConTeXt on Debian: The wiki entry

[Hans Hagen <pragma@wxs.nl>]

Frank � wrote:
> Hans Hagen <pragma@wxs.nl> 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
-----------------------------------------------------------------

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context