Why bundling lua?

[Panu Matilainen]

On Wed, 26 Apr 2006, Ralf Corsepius wrote:
> On Tue, 2006-04-25 at 19:47 +0300, Panu Matilainen wrote:
>
>> The point in having private copy of Lua is to be able to control the
>> version and exactly how it gets built so apt-lua scripts can be expected
>> to work identically everywhere.
> Well, you will also want to bundle glibc, gcc, libxml2, rpm and a couple
> of further packages for the same reasons then :-)

Apt doesn't lose commands or other key functionality if it's compiled 
against one glibc version or another.

>>  For example the embedded Lua in apt
>> includes additional rex and posix extensions, if those don't happen to
>> be available in the external Lua, script that works on one system
>> doesn't anymore work on another.
> Yes, ... but ... where is the problem? Check if these features are
> available and switch LUA-support off if these features aren't available
> in  system's run-time lua-libs or require apt-lua scripts not to use
> them.
>
> Wrt. this lua isn't any different from any other external library.

It is different in two ways: it's not available "everywhere" like, say, 
libxml2 is. Also few people know anything about it, or care about it as a 
language. Yet it's a very fundamental feature of apt-rpm IMO, which I 
don't want to get turned off just because the packager isn't aware of a 
little known language called Lua and how it should be packaged - various 
extensions included - for use with apt.

> AFAIU, lua in FE doesn't seem to have these extensions - What is the
> reason for doing so?

They're not included in standard Lua tarball. In case you haven't tried 
writing apt-lua scripts without those libraries, well life is *very* 
miserable without them and limits what can be done severely.

>>> I want to slimdown to tarball and get rid of code, such it doesn't have
>>> to be maintained as part of apt-rpm.
>>
>> For the reasons above, I'll rather keep the bundled Lua than start
>> slimming things for slimmings sake at the expense of consistency, ~1MB
>> tarball isn't exactly big in my book to begin with :)
> The problems isn't only size and building speed.
> There also is code quality, security etc.

Lua stays in the tarball, period. Security is of course an issue with 
bundled software always, that we just have to live with.

 	- Panu -