Re: [NTG-context] ConTeXt on Debian: The wiki entry
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? My apt shows errors with this line. Gerhard -- Gerhard Kugler Psychotherapeut Bensheim (Germany) http://www.psychotherapie-kugler.de ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Gerhard Kugler [EMAIL PROTECTED] 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) ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
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 - ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
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.
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.
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. 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)
If you don't make this change, you cannot use texexec for the
format regeneration, at all. (Formats created by texexec will
never be used because the fmtutil-generated old one is always
discovered first).
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.
* 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).
I have:
TEXFONTMAPS.dvipdfm = .;$TEXMF/fonts/map/{dvipdfm,dvips,}//
TEXFONTMAPS.dvipdfmx = .;$TEXMF/fonts/map/{dvipdfm,dvips,}//
TEXFONTMAPS.pdftex = .;$TEXMF/fonts/map/{pdftex,dvips,}//
TEXFONTMAPS.pdfetex = .;$TEXMF/fonts/map/{pdftex,dvips,}//
TEXFONTMAPS.xetex= .;$TEXMF/fonts/map/{xetex,pdftex,dvips,}//
TEXFONTMAPS.dvips= .;$TEXMF/fonts/map/{dvips,pdftex,}//
TEXFONTMAPS =.;$TEXMF/fonts/map/{$progname,pdftex,dvips,}//;\
$TEXMF/{$progname,pdftex,dvips}/{config,}//
this works fine (but it is perhaps a bit too verbose).
* 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.
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.
Cheers,
Taco
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Frank � wrote:
Hans Hagen [EMAIL PROTECTED] 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
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Taco Hoekwater [EMAIL PROTECTED] 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)
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
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
-
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
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
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Hans Hagen [EMAIL PROTECTED] 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
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Frank � wrote:
Hans Hagen [EMAIL PROTECTED] 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
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Hans Hagen [EMAIL PROTECTED] wrote: [ horror story snipped ] anyhow, by now, no alias file should be present in any tex root any more; it was a bad idea anyway I always thought that the purpose of the aliases file was that a non-existent (no, nay, never, nowhere ever) filename was aliased to an existent one, like in the documentation part: % documentation TETEXDOC.pdf teTeX.pdf etex-man.pdf etex.pdf pdftex-a.pdf pdftex.pdf testeuro.dvi eurosym.dvi If the rest of the aliases covers files that might exist as real files on some systems - I agree, what a bad idea. pool files normally are in web2c paths; future versions of pdftex and mpost have the pool file embedded so this problem will (hopefully) disappear Ah, I didn't know that. pdftex 1.40 doesn't have this already, has it? 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 Oh, yes, it is. Current kpse also has the side effect that on most systems, users are able to fill up the /var/ partition by generating pixel fonts... 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? 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 This is probably still a problem in standard-setup systems. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
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 - ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
[NTG-context] ConTeXt on Debian: The wiki entry
Hi everybody, this mail has a double purpose. At the end, there's a call for testers of a new (planned) Debian ConTeXt package that would be updated more frequently than now (at least in unstable and testing), where ConTeXt is tied to teTeX's or TeXlive's release cycles. But first, I'd like to talk about http://wiki.contextgarden.net/Debian_installation Are some of the people around who wrote this? I found some information in it misleading and in part just wrong (this has already been pointed out two weaks ago by plink), and have started to edit the page to change the parts that give us, the Debian TeX maintaines, most headache. But in the lower part, Steps to finish a first context upgrade, I felt lost. If these steps are really needed, then there's something seriously wrong in Debian's (and probably upstream's) packaging of ConTeXt. Therefore I didn't just change the text to reflect how I think it should work. Instead, we should try to figure out together whether it in fact does not work as it should, and then fix the Debian packages (hopefully still possible for etch). So the specific question I have are: - 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. - 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? Finally, here comes Norbert Preining's Call for Testers: Dear all! We = Debian TeX maintainers searching for users of the Debian Operating Systems which are also using ConTeXt. Currently Debian etch (testing) and sid (unstable) contains packages for TeX live 2005. But this contains a bit old ConTeXt version, so users are asking us to update ConTeXt. We have prepared a updated ConTeXt package for Debian, based on the latest released version (2006.08.08), and would ask you to help use testing, as we are not experienced in ConTeXt type settings. I checked some simple documents from the ConTeXt Garden, and they worked, but more detailed testing would be nice. If you have interest, please contact us at [EMAIL PROTECTED] 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. Thanks a lot and all the best Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive) ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Hi Frank, A ConTeXt's package for debian will be great ! Frank Küster a écrit : Hi everybody, this mail has a double purpose. At the end, there's a call for testers of a new (planned) Debian ConTeXt package that would be updated more frequently than now (at least in unstable and testing), where ConTeXt is tied to teTeX's or TeXlive's release cycles. But first, I'd like to talk about http://wiki.contextgarden.net/Debian_installation Are some of the people around who wrote this? I found some information in it misleading and in part just wrong (this has already been pointed out two weaks ago by plink), and have started to edit the page to change the parts that give us, the Debian TeX maintaines, most headache. But in the lower part, Steps to finish a first context upgrade, I felt lost. If these steps are really needed, then there's something seriously wrong in Debian's (and probably upstream's) packaging of ConTeXt. Therefore I didn't just change the text to reflect how I think it should work. Instead, we should try to figure out together whether it in fact does not work as it should, and then fix the Debian packages (hopefully still possible for etch). My contributions was to copy Install a Metapost update and Install a pdfTeX update from tetex 3.0 Install to Debian Install... From my pov, ConTeXt is really great because of the reactivity of the devs. As a consequence, new astonishing features are often added... but there is a price: update often to the latest realease + install the latest metapost and the latest pdfTeX (moreover, here I need the latest beta of pdfTeX). IMHO, it will be nice if the deb provides debian's specifics + interactiv cont-tmf.zip download + install according debian specifics... but there will be dependencies problems... Maybe a full standalone context is the solution (with metapost, pdfTeX and all the binaries we need coexisting with the tetex's one) ? Dunno... Last point, it could be nice to have beta packages for ConTeXt an m-bib (separated)... So the specific question I have are: - 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. It's the way ConTeXt does... ConTeXt's gurus have surely good reasons so I let them answer... - 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? idem Finally, here comes Norbert Preining's Call for Testers: Dear all! We = Debian TeX maintainers searching for users of the Debian Operating Systems which are also using ConTeXt. Currently Debian etch (testing) and sid (unstable) contains packages for TeX live 2005. But this contains a bit old ConTeXt version, so users are asking us to update ConTeXt. We have prepared a updated ConTeXt package for Debian, based on the latest released version (2006.08.08), and would ask you to help use testing, as we are not experienced in ConTeXt type settings. I checked some simple documents from the ConTeXt Garden, and they worked, but more detailed testing would be nice. If you have interest, please contact us at [EMAIL PROTECTED] 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. Thanks a lot and all the best OK, thanks, I'll do it as soon as I have a little more time (after my PhD defense... ;) ) Regards, Frank Renaud ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
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. - 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/ - 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. Greetings, Taco ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Taco Hoekwater [EMAIL PROTECTED] 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) ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Frank Küster wrote: - 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? Yes, it was, Yes, 'they' were aware, and no, 'they' did not want to fix fmtutil. 'They' only dropped the separate format extensions and then decided that implementing a replacement was too much effort. - 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? Nothing at the moment, AFAIK. But potentially lots of things. For instance: the next version of context will support non-kpathsea file searching, so it will have to initialize its database somewhere. It may want to/have to delete obsolete files and/or merge local configuration files with new released version. Or precompile patterns files or lua scripts, strip and optimize source files, and perhaps generate font metrics in one format or another. ConTeXt comes with its own font map files, so there is no real reason to fix updmap but if you want to the main problem is this: you have to extend it so that it does not treat dvips and pdftex map files as identical. 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. Greetings, Taco ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Taco Hoekwater [EMAIL PROTECTED] 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) ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
http://wiki.contextgarden.net/Debian_installation Are some of the people around who wrote this? I wrote some of it (hangs head in shame) by typing in all the steps I had to use on my Debian stable/testing system to get a newer ConTeXt to work with tetex 3.0 as the basis. I agree, it is confusing and I hope it can be improved. In the previous discussion, the issue came up of whether ConTeXt should be installed per user or for the whole system. The Debian_installation instructions on the wiki are for a per-user install, because I couldn't figure out a robust way of having an easily updatable installation that goes in TEXMFLOCAL. 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? -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1. ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
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 - ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] ConTeXt on Debian: The wiki entry
Hans Hagen [EMAIL PROTECTED] 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.
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}
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.
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.
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?
TIA, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
