Re: ConTeXt on Debian: The wiki entry

["Frank Küster" <frank@kuesterei.ch>]

Hans Hagen <pragma@wxs.nl> wrote:

> 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)