Question about embedded Lua
Hi all,
As per Debian policy, programs and libraries are generally not allowed
to embed their own copies of libraries that are present in another
package, in order to avoid duplication of code and to enable security
updates by updating shared libraries. In general, this is a good rule,
but I'm wondering if an exception can be made in certain circumstances.
Specifically, I'm thinking about Lua.
New versions of Lua aren't backwards compatible with old ones. In other
words, Lua 5.3 is as different from Lua 5.2 as Python 3 is from Python
2. If someone wants to include Lua in their program, they have several
options:
1. Always embed the latest version of Lua, breaking backwards
compatibility as it gets upgraded
2. Pick a single version of Lua and stick with it forever, missing out
on the benefits of newer versions but retaining backwards compatibility
3. Embed *multiple* versions of Lua, allowing the end user to select
the version they want, which allows them to reap the benefits of the
upgrade while still retaining backwards compatibility
Let's say someone goes with the 3rd option. I don't see how that could
be made to work without embedding a copy of Lua inside the program
itself, mangling the symbol names to avoid a conflict. In other words,
such a program could not link against the system versions of Lua, since
trying to link against liblua5.2 and liblua5.3 at the same time would
cause a symbol conflict. (I know there are versioned symbols, but does
this allow a program to link against multiple versions of the same
symbol? Even if it does, this seems very error prone.)
If such a program chose to embed multiple, modified copies of Lua for
symbol mangling, and did not provide the option to build against an
external Lua, would such a program still be eligible for inclusion in
Debian even though it violates the "don't include your own copies of
libraries" rule? Could an exception be made for this circumstance?
Kyle
Reply to: