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
