 |
lua-l archive |
|
|
||
|
On Tuesday, January 29, 2002, at 09:54 AM, Luiz Henrique de Figueiredo wrote:
The big question for me is whether to package pure Lua 4.0, or what I've been calling Lua 4.0.1: liblua40.so with lua_loadbuffer and lua_loadfileexposed, in order to support the new readline, line-spanning /usr/bin/lua.Please package pure Lua 4.0. There is no official 4.0.1 or such. If you want, add the changes as patch file.
Yeah, I know there's no Lua 4.0.1, and it would be a bad idea to call it that. I'm just calling it that in my head for now.
Anyway, after applying the patches, what do I call the resulting libraries and binaries? I'm shipping binaries, so the user won't see the patch file.
The shared library liblua40-patched-with-loadbuffer.so.1.1 is completely compatible with all current uses of liblua40.so.1.0; that is a sufficient condition for it to share the same soname ("liblua40.so.1"). That doesn't mean they *should* share an soname, but it does at least seem reasonable.
There's a separate issue of whether the shipped lua.h should include definitions for lua_loadbuffer. My inclination would be "no", because it would force people to stick with the lua-4.0.tar.gz interface unless they explicitly declared lua_loadbuffer.
What do I do with the accumulated bug fix patches from lua-l? Can I patch them into /usr/lib/lua40.so.1 and /usr/bin/lua40, or do I need to get a new name for that?
I think it would be useful to have an official Lua 4.0.1 with lua_loadbuffer and bug fixes. The charter would be "no third party code", "no significant new features" (lua_loadbuffer just being an existing function exposed), "completely backwards compatible". I think that means "no lua 4.1 /usr/bin/lua".
I'm willing to do the legwork for putting together such a patch/distribution. I believe it would maintain the "no third party code" standard, as it's just tecgraf people's patches that are being applied.
Jay