Re: Question about embedded Lua
Hi Kyle,
On Thu, Jul 25, 2019 at 10:27:42AM -0400, Kyle Edwards wrote:
> 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
I think there is another option, as embedding lua is a bad idea for the reason
you have already quoted: There are currently two (three with experimental) lua
versions available in Debian, so you should run one of those. This is especially
true if the to-embedded-library is someting like the caliber of lua.
This is not different like the python people are doing: There is python3 and
python2 in Debian, noone would embed python itself in python packages.
(Disclaimer: I'm not maintaining lua $stuff, so there might be details I'm not
aware of. It might be that there is a single preferred version for bullseye
which you
should aim for.)
If you really need to embedd lua (prepare to have strong arguments for that,
the one you've listed are likely not), please talk to the security people
> 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?
The 3rd option would mutiply the problems imposed by embedding lua and
also mulitply the efforts on your side (you have to test every combination…
So I'm think you do not want this one only because of that already.
Also, this would multiply work on other teams (e.g security), so I guess
this one be the least preferred one.
--
tobi
Reply to: