deep breath
texlive bundles lua. Specifically, a patched version of lua 5.2.4 with extra functions exported. I don't really want to try to patch texlive to use modern lua, nor am I particularly excited at the prospect of going into that tangled maze of pain to try to get it to use the compat-lua package (assuming that I exported the extra functions in there too, which I'm not really a fan of).
texlive has been doing this for a while, probably since it was added to Fedora. Can we just agree that texlive is sick, twisted, wrong, but necessary and grant a bundling exception for lua?
"texlive" is a pretty huge thing. Is there some specific part of texlive which requires this? It would be good to know exactly what needs it. TeX itself got along for quite a long time before line one of lua was written, after all. It would also be nice to at least know the history behind this fail. Should we assume that someone just crammed it in there at some point and said "well, that's it, we'll never ever want to update it again"?
I ask, basically, because I'd much rather say "it's OK for this component of texlive (which probably should be its own package) to bundle lua" instead of "anything associated with texlive can do whatever with lua; pile in a few different versions if you like".
Also bundles luajit. I'm poking around and will try to talk with the http://www.luatex.org/ folks to see what's up.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-09-24/fpc.2015-09-24-16.00.txt):
...we seemed mostly in favour of it, basically trusting that you'd do the right thing, but orion wanted to spend a bit more time looking at the package/etc ... we'll probably vote on it next week.
I took a closer look at how lua is used in luatex and it appears that it is actually extending lua - e.g. it builds against internal lua headers. So there is really no way to build against a system lua. Still need to look at luajit usage.
Started a discussion with upstream: http://www.ntg.nl/pipermail/dev-luatex/2015-September/005361.html
Luatex is extending Lua in at least four areas by adding new functions, and replacing some. liolibext is the most "entangled" due to duplicating liolib code, and lstrlibext also uses some Lua internals that are not normally exposed to consumers of Lua (e.g. lua_lock). As such it is tied to the version it is targeting and needs to build against private headers.
liolibext.c: {{{ / This extension only replaces one function: io.popen() and two metatable entries: f:read() and f:lines() but unfortunately it has to copy quite a bunch of lines from the original liolib.c to do so. /
}}}
Luatex people did not think it appropriate to push their changes upstream, though I don't quite follow it:
No. The development by Lua is very well embedded in academic research and should not be poluted by whatever a user comes up with.
In luatex there will always be overloads in i/o because of the very nature of tex / tds / web2c / distributions: standardized file lookups and security.
I didn't not look at what exactly the changes to popen/read/lines were.
So the choices seem to me to be to either drop luatex (perhaps not such a big deal as this is kind of an experimental project) or grant the exception.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-10-01/fpc.2015-10-01-16.00.txt):
FYI: I just filed https://bugzilla.redhat.com/show_bug.cgi?id=1268144
As FPC is no longer in the business of approving bundling requests, please feel free to bundle as you wish. Yes, that means you can even bundle things which have open CVEs. Of course, do add Provides: bundled(lua) = 5.2.4.
Metadata Update from @orion: - Issue assigned to james
Login to comment on this ticket.