[tex-live] Having a .fmt for different engines

Karl Berry karl at freefriends.org
Sat Jan 6 00:18:32 CET 2007

> We've discussed a possible fmtutil patch (and texmf.cnf update), but  

Regardless of the merits, I don't like the timing.  There is obviously a
workable scheme in existence (context creates its own fmt's, right?),
because we've released without this purported feature since day one.  So
can someone please explain why it is become so desirable all of a sudden
that we need to push through this nontrivial change to system setup at
the last second?

Another aspect of the timing is documentation.  I very much enjoyed
writing things like "there were no directory or other infrastructure
changes" in the doc.  This would blow that out of the water.  I'd have
to document it (not fun), and then it would have go back to the
translators.  At this point, I don't like it.

However, I should say that the timing is not up to me.  Hans, Klaus, and
Volker are controlling the schedule at this point.  If they think this
change is worth the risk of a late or problematic release, it is their
choice.  Last I heard, the hard deadline was to have everything ready
for the upcoming Dante meeting.

I don't buy "because we're adding xetex we need to do something now".
We've had multiple engines since forever (tex, etex, pdf[e]tex, omega,
aleph, ...).  As far as I know, they are all supported on an equal basis
already.  I see particularly nothing different about xetex in terms of
infrastructure need.

Finally, as for the merits, it is not clear to me what we (let alone the
users) are gaining.  Like te and rk, I fail to understand the problem
with using unique file names instead of subdirs.  That is the natural
way to do things with stupid kpathsea.  Again, to me this seems the
wrong time to even have the debate ...


More information about the tex-live mailing list