Why bundling lua?

[Panu Matilainen]

On Wed, 26 Apr 2006, Ralf Corsepius wrote:

> On Tue, 2006-04-25 at 22:00 -0700, Panu Matilainen wrote:
>> 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.
> It does: Many parts of glibc are optional, a lot of functionality is not
> available in older versions.
>
> It looses wrt. g++ (On RH-7.3):
> ...
> g++ -DHAVE_CONFIG_H -I. -I. -I../include -DLIBDIR=\"/opt/apt/lib\"
> -DPKGDATADIR=\"/opt/apt/share/apt\" -I/usr/include/libxml2
> -I/usr/include/rpm -g -O2 -MT contrib/hashes.lo -MD -MP -MF
> contrib/.deps/hashes.Tpo -c contrib/hashes.cc -fPIC -DPIC -o
> contrib/.libs/hashes.o
> contrib/hashes.cc: In method `bool Hashes::AddFD (int, long unsigned
> int)':
> contrib/hashes.cc:33: `::min' undeclared (first use here)
>
>
> It also looses wrt. libxml2 (On RH-7.3):
> ...
> g++ -DHAVE_CONFIG_H -I. -I. -I../include -DLIBDIR=\"/opt/apt/lib\"
> -DPKGDATADIR=\"/opt/apt/share/apt\" -I/usr/include/libxml2
> -I/usr/include/rpm -g -O2 -MT rpm/repomd.lo -MD -MP -MF
> rpm/.deps/repomd.Tpo -c rpm/repomd.cc  -fPIC -DPIC -o rpm/.libs/repomd.o
> rpm/repomd.cc: In method `bool repomdRepository::ParseRelease
> (basic_string<char, string_char_traits<char>,
> __default_alloc_template<true, 0> >)':
> rpm/repomd.cc:41: `XML_PARSE_NONET' undeclared (first use this
> function)

Not compiling against some library version is different from losing 
runtime functionality. The above cases we might want to fix actually, 
simply a matter of not testing current version on anything older than 
FC3/RHEL4.

> Besides this, libxml2 is known to be rather buggy. The version on FC4
> for example suffers from a pretty serious bug in its xmlReader
> interface.

Any pointers? Apt uses a pretty limited subset of xmlReader interface.. 
but if the bug affects apt we might want to do something about it.

>> Lua stays in the tarball, period.
> Bummer - Very poor decision.
>
>
>>  Security is of course an issue with
>> bundled software always, that we just have to live with.
> We don't have to, but you decided to infect apt with it and obviously
> are relying on exploiting non-public interfaces.

There's nothing non-public about posix and rex extensions to Lua, they're 
just not part of the core language but external libraries which happen to 
be important enough in the context of apt-rpm scripts to make sure we 
always have them.

 	- Panu -