Frank � wrote:
After a succesful update, you have to run
# texexec --make --all [--xetex | --aleph | --pdftex] <formats>
Where <formats> are the desired formats to run. The accepted list at the moment is: the eight ConTeXt formats, in both long ("cont-en" etc.) and short from ("en","nl","de","it","fr","cz", "ro","uk"), and "mptopdf", and the metapost mems "mpost" and "metafun".
So I guess this is the call that would also be needed if the update itself goes via a package management, i.e. if one installs a new version of the Debian ConTeXt package.
i think that it depends on what users want to use (pdftex, aleph, xetex, luatex, a combination) ok, one can play safe and just generate them all for the english user interface
So I guess TeXlive (and the existing teTeX packages within Linux/BSD/... distributions) should do that, so that modern ConTeXt just works.
If you are not root, then
just curious: how many tex users or people updating tex don't have root permissions
and so on. I'm not sure, however; this of course depends on which progname ConTeXt uses (so it might need to be TEXFORMATS.cont-xetex or whatever).
the progname is always 'context' there is no functional difference between context's, only user interface languages may differ, so for pdftex, xetex etc the same context is used; backend support is loaded runtime; so, there is not, as with latex, a pdfcontext or so: backend support has always been isolated in driver files; the TEXFORMATS variable should have an /{engine,} appended which makes the engine specific formats end up the and be searched there (because formats are always generated in a current path, texexec will chdir to an engine path when making a format) so, pdftex, xetex, aleph, ... all use cont-en.fmt for the english user interface (used to be cont-en.efmt, cont-en.ofmt, etc); using different names for the formats does not make sense since the functionality is mostly the same
I think, with the TEXFORMATS.$engine setup working, it should be possible to use both, fmtutil and texexec, and get the same formats - texexec might still be better in doing other update tasks.
the problem with this is that there is only one dimensions: progname, so TEXFORMATS.context is ok, and TEXFORMATS.xetex is undefined (actually $engine is unset in many cases)
* TEXFONTMAPS is also wrong: it makes pdftex (and dvipdfmx as well, I guess) find the mapfiles for dvips before their own mapfiles (those are shipped with ConTeXt).
This also sounds like a bug in TeXlive/teTeX.
if i'm right Karl added it after we discussed this feature but i didn't check it
* Lastly, ctxtools --update does a kpsewhich on context.tex to find where to install the updated files. That only works if you have write permission for that directory (i.e. you are root), or if you have done a private install already.
So this means -update will always try to overwrite an existing installation, and not automatically search for a writable directory that's earlier in the TEXMF path? Even not as a fallback? This sounds as if this tool could be improved.
def locatedlocaltree tree = Kpse.used_path('TEXMFLOCAL') unless tree && FileTest.directory?(tree) then tree = Kpse.used_path('TEXMF') end return tree end so, it prefers texmflocal; so far no one asked for different methods but it can always be improved (and will be on request)
I think that is all, but I may have missed something, so if you read this message and know a thing or two about updating, please double check my text. Thanks in advance.
I think it does help a lot, and we can work from there, testing with the Debian ConTeXt package.
ok, thanks. there are debian users on this list so testing should be no problem 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 -----------------------------------------------------------------