From: Hans Hagen <pragma@wxs.nl>
Cc: Taco Hoekwater <taco@elvenkind.com>
Subject: Re: INstalling a new version of context
Date: Mon, 09 May 2005 22:21:03 +0200 [thread overview]
Message-ID: <427FC62F.8090307@wxs.nl> (raw)
In-Reply-To: <f03b6a44050509084530153899@mail.gmail.com>
bb wrote:
> It would be a very good thing if stock texlive could reside in texmf
> and texmf-dist while your complex setup and bleeding edge stuff could
> reside in texmf-var, texmf-local, texmf-fonts, texmf-extras, etc. I
> can guess at several reasons why this might not be feasible. But it
> would be a worthy goal for both texlive and context to make such
> interoperability and upgradability trivial. The current confusion
> over engine support, for example, is simply maddening.
>
> Texlive is the closest thing that exists to a standard TeX "platform".
> One of its virtues, in my opinion, is its inflexibility. It is fairly
> stable over time and does not vary significantly across distributions
> like tetex does.
>>Have you complained to the TeXlive maintainers as well?
>
> Haven't I made enough enemies already :-)
not yet -)
TeX Live is both a binary distribution and a collection of resources.
Normally context -as shipped with tex live- works ok, apart from changes in non
context specific parts that went unnoticed (chnages in font names, changes in
patterns, and such) which may lead to broken functionality.
Sebastian always tries to get the latest greatest context in there and tests it
as well, so the problem is not in tex live as it is.
The binaries are a different story. There is a close relationship between
binaries like pdftex, mpost on the one hand and kpse and texmf.cnf on the other
hand; and then there are of course the scripts that call these programs.
It has always been kind of a struggle to make the scripts work for all
platforms. The main reason for this is that the user interface of kpse is unix
based and assumes a certain shell. Also, some associated scripts (fmtutil,
updmap) are shell scripts. One can safely say that therefore tex live is mostly
a unix distribution. History has learned that it's kind of tricky to keep the
windows and unix versions in sync (if only because there are two source trees);
last year there has been several incompatible changes in tds and the binaries;
to mention a few:
- the multiple suffixes (efmt,ofmt,fmt,xfmt,..) were replaced by one (fmt) under
the assumption that the engine subpath would be used to distinguish between
aleph, pdfetex, xetex, etc.; unfortunately in practice this is not supported due
to the fact that it's too complex to incorporate in the form generating scripts;
---> this is why in texexec i need to deal with it myself and also need to catch
old cases etc; shell escaping is thereby rather painful.
- font paths (enc/map) has changed in an downwards incompatible way ---> this
can be repaired by the textools script
- as usual there were changes in patterns that went unnoticed ---> this is why i
will start shipping context with its own pattern files
- the script paths has changed as well as the way to locate scripts in the tree;
which is quite painful fro those who run tex in integrated environments --> this
is solved by using texmfstart as stub [that way i can try to remain downward
compatible]
keep in mind that some context users use aleph/pdfetex/xetex alongside and that
many context users use fonts not present in the standard tree; so, we need to
deal with that ourselves
now, on my main machine i use windows and on the webservers linux; i never had
problems in getting things running on windows, but unxi has always been
troublesome, esp in updating systems that had already some kind of tex
installed; this is why i always use the minimal distributions on unix:
setuptex.sh nicely isolated the tree from whatever present; it is a known fact
that, although tex live is rathere closely related to tetex, one should not
install both alongside: different selection, different installation etc; macosx
is yet another story but as far as i can see, gerben does a good job in
providing update paths (no surprose since tex on the mac is moving faster than
the rest)
it may be good to know that the last user group dvd actually shipped with
protext based on miktex; miktex also has an update policy; it would be
interesting to see what happens with the miktex for unix announcement.
currently fptex (or its more extensive version xemtex) is maintained
independently from the rest of tex live, thereby maing tex live more and more
unix adventure (apart from the resources tree)
another source of confusion is the fact that each distribution ships with
different trees (texmf, texmf-local, texmf.local, texmfte, texmfgw, texmf-dist,
texmf-doc, etc); here i always merge the common part into texmf, and put context
updates in texmf-local
if you want the best tree: take the texmf tree from the user group dvd; this is
a merge of the tex live trees, a bunch of ctan goodies, extra fonts etc;
personally i tend to consider manfred's tree as the default one
so ... it's a complex live out there
and .. don't blame the maintainers too much .. it's not trivial to keep track of
all changes in operating systems, compilers, libraries, macro packages etc ...
it's only unfortunate that the common binary base is developed in a bit too
platform bound way [but i try to hide as much as possible by using texexec cum suis]
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
-----------------------------------------------------------------
next prev parent reply other threads:[~2005-05-09 20:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050508100002.AAEAA127B3@ronja.ntg.nl>
2005-05-09 3:01 ` bb
2005-05-09 9:18 ` Taco Hoekwater
2005-05-09 15:45 ` bb
2005-05-09 17:01 ` Taco Hoekwater
2005-05-09 19:12 ` bb
2005-05-10 12:45 ` texexec.pl patch bb
2005-05-09 20:21 ` Hans Hagen [this message]
2005-05-07 18:01 INstalling a new version of context olibou
2005-05-07 20:29 ` John R. Culleton
2005-05-08 8:18 ` olibou
2005-05-08 20:40 ` Hans Hagen
2005-05-08 20:44 ` Hans Hagen
2005-05-09 10:24 ` John R. Culleton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=427FC62F.8090307@wxs.nl \
--to=pragma@wxs.nl \
--cc=ntg-context@ntg.nl \
--cc=taco@elvenkind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).