Norbert Preining wrote:
Dear Taco,
one of the lua Gurus here at Debian checked the embedded libs and found
that most of the included libs are very similar to upstream, and he
offered to push the few changes in your code to upstream.
What do you say? (See attached email, including the diffs between current
upstream of the lua libs and code in texlua).
TeX has alwaye been independent of external libraries, although for
pdftex it's possible to keep some libs external. Although the 'teams'
assume statics, its' up to the distributers to decide on external libs;
kpse has been an example for a long time already but that one lives
alongside tex.
For luatex it's somewhat different. Take for instance a moving target
like lpeg. Macro packages depend on the functionality as defined when
the luatex version came around. If some (maybe more recent) library is
used it might break things. And it might even be that at some point when
we have luatex version 1.0, we freeze on libraries (apart from bug fixes
of course). The same might happen with lua itself. If lua 6 comes around
we might add an extra lua engine but keep 5 around as well.
Loading libraries in luatex can become a nightmare esp when we thing of
mixes with luarocks and other distributions. As lua is meant for
embedding, the libs we use are also kind of internal.
Of course, pushing changes/patches upstream is great.
This is a tricky issue. In principle luatex, once stable, should run
decades as-is. An independent entity. On th eother hand, progress is
also a nice thing.
I can imagine a scenario where we have a static luatex as usual, but
when distributers want to go dynamic they should use the (in terms of
api) same libs as static. None of us is looking forward to getting bug
reports like "luatex+macropackage reports an lpeg error" which only
happens with non statics bins.
Also, i wonder, if luatex demands some specific lib version, how does
this translate to installation? Currently i can just drop a static
luatex bin in my tex bin path but what if a bunch of extra libs (maybe
already present but potentially conflicting) are used? Ok, we can
control things with the cpath variable, but that also adds another
variable to the game.
Anyhow, this needs quite a bit of thinking.
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
-----------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org