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).
Best wishes
Norbert ------------------------------------------------------------------------ Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org} JAIST, Japan TU Wien, Austria Debian TeX Task Force DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ BULDOOO a virulent red-coloured pus which generally accompanies clonmult (q.v.) and sandberge (q.v.) --- Douglas Adams, The Meaning of Liff
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).
But what happens then? Luatex becomes dependent on an external library that may or may not be distributed by debian (or anyone else)?
Best wishes, Taco
On Sa, 19 Dez 2009, Taco Hoekwater wrote:
But what happens then? Luatex becomes dependent on an external library that may or may not be distributed by debian (or anyone else)?
No, only that as long as the libraries in texlua are the same as upstream I can reuse the the packages in Debian.
And the advantage for you is that there are less changes if you incorporate new versions of upstream libraries.
I didn't suggest to actually remove the sources from your code!
Best wishes
Norbert ------------------------------------------------------------------------ Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org} JAIST, Japan TU Wien, Austria Debian TeX Task Force DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ `Time is an illusion. Lunchtime doubly so.' you should send that in to the "Reader's Digest". They've got a page for people like you.' --- Ford convincing Arthur to drink three pints in ten --- minutes at lunchtime. --- Douglas Adams, The Hitchhikers Guide to the Galaxy
Norbert Preining wrote:
On Sa, 19 Dez 2009, Taco Hoekwater wrote:
But what happens then? Luatex becomes dependent on an external library that may or may not be distributed by debian (or anyone else)?
No, only that as long as the libraries in texlua are the same as upstream I can reuse the the packages in Debian.
I don't understand this point. The files are statically linked, so how can there be any reuse?
And the advantage for you is that there are less changes if you incorporate new versions of upstream libraries.
But that is certainly true. Here is my opinion on those patches:
luafilesystem: that local patch will go away soon (it is possible to slide the new functions in elsewhere, where they are not interfering with the upstream).
luasocket: this (hstrerror) patch is good thing to go upstream.
luazip: this is not a local patch, I am just using an outdated version.
Best wishes, Taco
On 19.12.09 Taco Hoekwater (taco@elvenkind.com) wrote:
Norbert Preining wrote:
Dear Taco,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441595#47
And the advantage for you is that there are less changes if you incorporate new versions of upstream libraries.
But that is certainly true. Here is my opinion on those patches:
luafilesystem: that local patch will go away soon (it is possible to slide the new functions in elsewhere, where they are not interfering with the upstream).
The patch is still in the lualib used by luatex. Did you made already a decision if that code is needed (and should be pushed upstream to the lua project)?
Many thanks, Hilmar
Hi Hilmar,
On 11/28/2010 01:54 PM, Hilmar Preusse wrote:
luafilesystem: that local patch will go away soon (it is possible to slide the new functions in elsewhere, where they are not interfering with the upstream).
The patch is still in the lualib used by luatex. Did you made already a decision if that code is needed (and should be pushed upstream to the lua project)?
Thank you for reminding me, I had completely forgotten about this :(
I now am in the process of upgrading luatex to use luafilesystem 1.5.0, and I will move most of the extra functionality to a different source file, as I wrote above.
Nevertheless, there are two change sets that will remain in my version of the lfs.c file: one portability bug fix and one extension. Both of these are interesting enough to go upstream, in my opinion.
The portability fix is in get_dir(), where the stock lfs version assumes a glibc-style runtime library that calls malloc() automatically inside getcwd(). I got a compilation failure report on that, for the Sun Studio compiler on Solaris 10 Sparc.
The extension is an extra field thats is retunred by lfs.attributes(), named 'permissions'. This represents the file permissions as a simple 9-letter string (it uses "r", "w", and "x" only).
Best wishes, Taco
On 28.11.10 Taco Hoekwater (taco@elvenkind.com) wrote:
On 11/28/2010 01:54 PM, Hilmar Preusse wrote:
Hi,
luafilesystem: that local patch will go away soon (it is possible to slide the new functions in elsewhere, where they are not interfering with the upstream).
The patch is still in the lualib used by luatex. Did you made already a decision if that code is needed (and should be pushed upstream to the lua project)?
Thank you for reminding me, I had completely forgotten about this :(
Many thanks for fast response! I fowarded your E-Mail to the lua maintainer of Debian.
H.
Hi Norbert
No, only that as long as the libraries in texlua are the same as upstream I can reuse the the packages in Debian.
what does that mean in practice for your tex live installer? that it has to fetch (and compile) extra libs?
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 -----------------------------------------------------------------
2009/12/19 Hans Hagen pragma@wxs.nl:
what does that mean in practice for your tex live installer? that it has to fetch (and compile) extra libs?
Debian: Dynamic libs. TeXlive: Mostly static binaries.
Best Martin
Martin Schröder wrote:
2009/12/19 Hans Hagen pragma@wxs.nl:
what does that mean in practice for your tex live installer? that it has to fetch (and compile) extra libs?
Debian: Dynamic libs. TeXlive: Mostly static binaries.
yes but how does it check if the libs are functionally the same?
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 -----------------------------------------------------------------
2009/12/19 Hans Hagen pragma@wxs.nl:
yes but how does it check if the libs are functionally the same?
APIs are versioned and checked by the loader. http://en.wikipedia.org/wiki/Dynamic_library#Dynamic_linking It works. Mostly.
Best Martin
Martin Schröder wrote:
2009/12/19 Hans Hagen pragma@wxs.nl:
yes but how does it check if the libs are functionally the same?
APIs are versioned and checked by the loader. http://en.wikipedia.org/wiki/Dynamic_library#Dynamic_linking It works. Mostly.
sure, but i wonder what this means for the texlive updater ... will it also ship upgraded (or ancient) library versions then?
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 -----------------------------------------------------------------
On Sat, 19 Dec 2009, Hans Hagen wrote:
sure, but i wonder what this means for the texlive updater ... will it also ship upgraded (or ancient) library versions then?
We are talking only about the Debian packages here. The TeX Live (upstream, main) will NOT change to dynamic libs, sure not!!!
Best wishes
Norbert
---------------------------------------------------------------------------- Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org} JAIST, Japan TU Wien, Austria Debian TeX Task Force gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ---------------------------------------------------------------------------- FROSSES (pl.n.) The lecherous looks exchanged between sixteen-year-olds at a party given by someone's parents. --- Douglas Adams, The Meaning of Liff
Hi Hans,
On Sat, 19 Dec 2009, Hans Hagen wrote:
Debian: Dynamic libs. TeXlive: Mostly static binaries.
yes but how does it check if the libs are functionally the same?
md5sum of the source code.
Please do NOT care for what we are doing in Debian, that is our business and I will care for it.
I only try to get some changes in texlua pushed upstream and maybe compile some of the libs dynamically *ONLY* in Debian.
Best wishes
Norbert
---------------------------------------------------------------------------- Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org} JAIST, Japan TU Wien, Austria Debian TeX Task Force gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ---------------------------------------------------------------------------- KURDISTAN (n.) Hard stare given by a husband to his wife when he notices a sharp increase in the number of times he answers the phone to be told, 'Sorry, wrong number.' --- Douglas Adams, The Meaning of Liff
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 -----------------------------------------------------------------
-
Hans Hagen -
Hilmar Preusse -
Martin Schröder -
Norbert Preining -
Taco Hoekwater