Taco Hoekwater wrote:

Hi Frank,

Frank Küster wrote:

...

Are some of the people around who wrote this? I found some information

I do not use Debian and did not write that page, but I can answer your questions partially, at least.

Thank you - yes, this helps.

...

- Is it intended that context formats end up in $TEXMF/web2c/pdfetex/? If yes, why is that so? If not, we should rather find out why it happens and fix it.

Yes, it is. ConTeXt does not support only pdfetex, but all major engines, like XeTeX and Aleph. I have formats in:

$TEXMF/web2c/aleph/ $TEXMF/web2c/luatex/ $TEXMF/web2c/pdfetex/ $TEXMF/web2c/xetex/

Ah, okay, that's clear. Has this already been this way one year ago when texlive2005 was released? Do you know whether the TeXlive developers are aware of that?

...

- Why does it make a difference if the formats are created by fmtutil instead of texexec (Except for the output directory)? Should the upstream packaging be changed so that fmtutil is never used, but texexec, or should fmtutil be fixed to produce the same as texexec?

It is almost certainly better to ignore/block fmtutil and use texexec instead. Properly setting up a ConTeXt update is not necesarily limited to format generation only.

Hm. What are the other things that need to be done? This is in fact an issue that affects not only Debian, but TeXlive and probably most TeX distributions. They currently assume that after an update of some files and/or executables, it's sufficient to run mktexlsr (possibly more than once), updmap(-sys) and "fmtutil(-sys) --all". If this is not sufficient for ConTeXt, there are two possibilities: - fix fmtutil and updmap so that they do the right thing for ConTeXt - or implement a way to automate calling texexec. This would include using some configuration file, since not everybody who has aleph or xetex installed also wants a context format for this engine. To me, as a TeXlive and teTeX guy, it seems preferrable to choose option 1 and fix the existing distribution scripts. However, I don't know yet what else is needed when ConTeXt is updated, therefore I might be wrong, and switching to texexec might actually be better. But then this should be done consistently, and fmtutil should drop context handling completely (or just call texexec). Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)

Taco Hoekwater wrote:

...

To me, as a TeXlive and teTeX guy, it seems preferrable to choose option 1 and fix the existing distribution scripts. However, I don't know yet what else is needed when ConTeXt is updated, therefore I might be wrong, and switching to texexec might actually be better. But then this should be done consistently, and fmtutil should drop context handling completely (or just call texexec).

I am very much in favor of using texexec for everything related to ConTeXt.

Can you point me to the place where it is documented which calls are needed to be called - when ConTeXt is updated - when any of the engines is updated? I don't use ConTeXt myself, and I always have problems finding the relevant places in the documentation, sorry... Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)

Taco Hoekwater wrote:

Frank Küster wrote:

...

Can you point me to the place where it is documented which calls are needed to be called

I was going to say: on the wiki, but that clearly wouldn't work this time.

To actually update ConTeXt, assuming you already have a relatively modern context installed, you say

# ctxtools --update

and that fetches the zip file(s) from the pragma site (or a mirror), unpacks them, and updates the various perl and ruby scripts that come with ConTeXt.

When this is done on a system where ConTeXt first came with a TeXlive or teTeX installation, will this replace existing files, or will it put the updated new files in TEMXFLOCAL or TEXMFHOME, respectively? Ah, I think you have answered this already below.

You have to be root for this when you want to update the global install, otherwise you have a few extra caveats, see below.

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.

This works fine if you are root, and had a previous context update done already. If you have not already and/or are not root, then you have two big problems:

* TEXFORMATS as shipped with teTeX/TL is uncomplete: there is that missing format-specific subdirectory.

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

you have to create a local texmf.cnf to overrule the default texmf.cnf. I have:

TEXFORMATS = .;$TEXMF/web2c/{$engine,}

because context's texexec pushes the $engine setting to the environment, this works fine (Originally this was supposed to be handled by kpathsea, but like I said, that never got off the ground)

It might be possible by setting, in texmf.cnf, TEXFORMATS.xetex = .;$TEXMF/web2c{xetex,} TEXFORMATS.pdftex = .;$TEXMF/web2c{pdftex,} 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).

Not using texexec is not a big deal in itself, as long as you restrict yourself to using pdfetex and know how to edit the fmtutil config file, I guess. That's why you sometimes see that approach promoted on the wiki.

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.

* 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.

* 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.

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. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)

Frank Küster wrote:

...

After a succesful update, you have to run

# texexec --make --all [--xetex | --aleph | --pdftex] <formats>

..

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.

Yes.

...

This works fine if you are root, and had a previous context update done already. If you have not already and/or are not root, then you have two big problems:

* TEXFORMATS as shipped with teTeX/TL is uncomplete: there is that missing format-specific subdirectory.

So I guess TeXlive (and the existing teTeX packages within Linux/BSD/... distributions) should do that, so that modern ConTeXt just works.

Yes. But Hans and I gave up trying to convince the teTeX maintainers a while back, and we are not any more willing to spend even more time on doing that (even though the situation may have improved).

It might be possible by setting, in texmf.cnf,

TEXFORMATS.xetex = .;$TEXMF/web2c{xetex,} TEXFORMATS.pdftex = .;$TEXMF/web2c{pdftex,}

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

It is not the user-supplied progname, but the executable engine name. The progname is always set to 'context' for ConTeXt, otherwise variables like TEXINPUTS and the memory sizes would need many more entries main_memory.cont-en-xetex main_memory.cont-de-xetex etc. That is why there is a separate $engine.

...

Not using texexec is not a big deal in itself, as long as you restrict yourself to using pdfetex and know how to edit the fmtutil config file, I guess. That's why you sometimes see that approach promoted on the wiki.

I think, with the TEXFORMATS.$engine setup working, it should be possible to use both, fmtutil and texexec, and get the same formats -

Agreed.

texexec might still be better in doing other update tasks.

Also agreed.

...

* 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.

Yes, I think so: it needs a few more TEXFONTMAPS lines in texmf.cnf.

...

* 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.

That is true, ctxtools is very new tool that could definately be improved. Cheers, Taco

plink@veribox.net wrote:

I am getting a 648 line diff file when I compare two different 1.3.3 versions of the ctxtools.rb file.

indeed, i only change numbers when i feel that there is are real changes (

One of them, the smaller and older one, had some problems with quotes around environment variables, and it couldn't really upgrade the system because of a problem with unzip and execute permissions on texmfstart.rb

The other one has the same problem with execute permissions on texmfstart.rb, ending in the *slightly* dutchified report():

unable to remak formats

Or is there a way to call texmfstart.rb from the unix stub files without giving it execute permissions?

i dunno, but "ruby pathtotexmfstart ... " should work since then we're talking about text files 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 -----------------------------------------------------------------

Frank � wrote:

...

Yes, it is. ConTeXt does not support only pdfetex, but all major engines, like XeTeX and Aleph. I have formats in:

$TEXMF/web2c/aleph/ $TEXMF/web2c/luatex/ $TEXMF/web2c/pdfetex/ $TEXMF/web2c/xetex/

Ah, okay, that's clear. Has this already been this way one year ago when texlive2005 was released? Do you know whether the TeXlive developers are aware of that?

sure, but as taco explained in a previous mail, it was considered to be to complicated to adapt fmtutil to this which is why texexec tries to take care of it

...

It is almost certainly better to ignore/block fmtutil and use texexec instead. Properly setting up a ConTeXt update is not necesarily limited to format generation only.

Hm. What are the other things that need to be done?

texexec can instruct context in ini mode what patterns to preload, which font/encoding to default to, which combination of interface and message interface to use, etc in the case of luatex (we're experimenting with that now) it may also involve preparing lua startup scripts in the case of kpse overloading and such

- fix fmtutil and updmap so that they do the right thing for ConTeXt

i cannot answer that bacuse i don't use updmap but others on this list may know

- or implement a way to automate calling texexec. This would include using some configuration file, since not everybody who has aleph or xetex installed also wants a context format for this engine.

indeed; for now you can safely assume that those using aleph of xetex will make formats with "texexec --make --xetex | --aleph" if only because they need to be able to tweak their system to the latest features in those systems anyway (esp xetex involves more than just the xetex binary)

To me, as a TeXlive and teTeX guy, it seems preferrable to choose option 1 and fix the existing distribution scripts. However, I don't know yet what else is needed when ConTeXt is updated, therefore I might be wrong, and switching to texexec might actually be better. But then this should be done consistently, and fmtutil should drop context handling completely (or just call texexec).

just calling texexec may be a safe option; handling context directly is ok, but then it should be able to handle engine paths (but that has been fixed by now, if i understood the other mails right) 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 -----------------------------------------------------------------

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 ... ; 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; 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), 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 -) but luatex will make thinsg better (we hope) 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 -----------------------------------------------------------------

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

Frank � wrote:

Hans Hagen 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?

the problem is that it is not really discussed we accidentally stumbled into this when at a tug conference workshop attendents could not hyphenate; the problem was that pattern files were renamed, but aliased in an 'alias' file in one of the texmf roots; when looking at this file, more funny aliasing was taking place and i found out that quite some font problems were resulting from this, i.e. if one refers to font 'abc' which is aliased on one system but not on another ... ; normally such things are (off list) discussed with karl who then sort things out in tex live; when, at user group meetings, i had talks about 'contexts way of dealing with patterns and pattern files' and mentioned this alias mess, it was interesting to see tex experts launching up their laptops and scratching their heads over this unknown obscure aliasing feature ; in the end we found out that it was also the cause of some 'hyphen.tex' not being the real 'hyphen.tex' problem; anyhow, by now, no alias file should be present in any tex root any more; it was a bad idea anyway

...

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.

pool files normally are in web2c paths; future versions of pdftex and mpost have the pool file embedded so this problem will (hopefully) disappear

...

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.

texmfstart somefile will launch somefile, i.e. it is the script launcher; by using texmfstart, one can be sure that the right one is found (it also passes some info to underlying progs/scripts so that redundant kpsewhich calls don't take place; it's teh context way of dealing with non-downward compatible texlives; (it has an embedded kpsewhich written in ruby but this is disabled by default; it can also act as kpse servlet [serving multiple independent trees]; yet another feature is that it can be uses as: texmfstart --tree=sometree somescript ..... which us handy when running from cgi scripts (for that purpose it can initialize independent trees based on simple cross platform env var definiton files) well, it can do a bit more, like launching documentation and so (context ships with more tools: textools, tmftools, ctxtools, etc and when seldomly used, starting them with "texmfstart ctxtools" instead of stubs makes sense; the tex bin trees ship with potentially name-conflicting stuff, like 'access' and by launching scripts this way there is less danger of clashing names)

...

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.

sure, one can use \pdfmapfile{somename} in any package we can even do without map files for pdftex, just use \pdfmapline

...

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.

ah, i see

...

...

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

no var indeed; but indeed it should make no difference

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

i could add that feature to ctxtools --update

...

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.

they serve different purposes just like the tetex sys ones do ; for sure admins can add trees, but it would be handy if the fonts and project vars would be in the texmf list -)

...

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.

hm, interesting; lean and mean texmf.cnf files can speed up things a lot when playing with luatex (where i intend to replace kpse completely with a lua based variant) it is possible to have format specific file databases; this runs much faster; this whole ls-r stuff is pretty outdated

...

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.

ok

...

...

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

sure, but (i'm not sure if this is still true) running tex live alongside a tetex was always kind of problematic due to path settings and this autoparent mess then deriving locations of texmf.cnf from it luckilly the number of vars that one needs to set to get a nicely isolated tree is not that large (texmf, texmfcnf, texformats, and a few more)

I'll see that I or Norbert Preining look into this and come back with a more constructive proposal.

ok, thanks, 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 -----------------------------------------------------------------

Frank � wrote:

Ah, I didn't know that. pdftex 1.40 doesn't have this already, has it?

not that i know, but the latest mp may do it already (esp mp is tricky because binary and pool have different names)

Karl (or was it Olaf?) once said there are plans for a complete replacement of libkpathsea, named kpse - would that be obsolete with luatex? Could there be a C wrapper about lua's kpse?

i have (an experimental) luatools.lua which acts like kpsewhich and is just as fast as kpsewhich at some point it may end up in the context distribution as playground; 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 -----------------------------------------------------------------

Gerhard Kugler wrote:

On Mon, Oct 23, 2006 at 10:35:30AM +0200, Frank Küster wrote:

...

or, if you have a bit experience, you can straight away add deb http://www.tug.org/texlive/Debian/ context/ to your /etc/apt/sources.list file and install context. After this, please tell us our experiences/failures/suggestions.

Frank,

is this truely a valid line for sources.list?

Yes, I've got plenty of those.

My apt shows errors with this line.

which errors? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)