[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua within Debian
- From: Jay Carlson <nop@...>
- Date: Mon, 11 Feb 2002 21:51:49 -0500
On Monday, February 11, 2002, at 06:57 PM, Daniel Silverstone wrote:
On Mon, Feb 11, 2002 at 09:45:46PM -0200, Luiz Henrique de Figueiredo
wrote:
I noticed you didn't expose lua_loadbuffer as an external symbol in
the shared library.
Lua 4.0 officially has no lua_loadbuffer and friends.
*Please*, package the official Lua 4.0 code. You may want to add the
patch
as a separate thing, of course. Thanks.
Hmm, I can either package it in the "Debian version" of lua 4.0 or
else I
could provide an "alternative" liblua package.
My current favourite is to make the symbol exposed but guard the
definition
of it in lua.h with something like
#ifdef DEBIAN_LOADBUFFER
....
#endif
How does that sit with people?
The only other thought I have is to NOT change their names, but just
remove the static flag. That way, liblua.so is not exporting anything
new in the public lua_foo namespace.
The alias lua_loadbuffer could then be applied either through a #define
or a function exported in another library. Or maybe better yet, we
throw it in the Debian namespace like dllua_loadbuffer.
In any case, the goal is to make sure developers using this function
understand that it is not a standard function. If Debian users were
building from source, we could just tell them to apply a patch to the
pristine sources, but they use binaries, and there are significant
benefits to maintainers, developers, and end-users in not shipping two
conflicting versions of a shared library when the differences are so
small.
(BTW, Debian regularly ships heavily patched versions of other
interpreters. tk8.0 through tk8.2 ship not only with a full set of
internals include files, but also with the "plus" patch applied, which
exports significant user-visible functionality.)
Jay