Why bundling lua?

[Ralf Corsepius]

On Tue, 2006-04-25 at 22:38 -0700, Panu Matilainen wrote:
> 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.
gettext is a run-time functionality, pthreads are,  nss is, pam is etc.
etc.

>  The above cases we might want to fix actually, 
> simply a matter of not testing current version on anything older than 
> FC3/RHEL4.
Nope, the 1. case above is simply bad code in apt and easy to fix.

The latter is apt-rpm blindly relying on a feature not being available
in the version on RH-7.3. 

> > 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.
Check the xml2 list (It had been reported in the last 2 months or so).

Libxml2 has problems with return status values when xmlReader would need
to traverse from a "down node" to an "upperlevel node. This would hit
apt-rpm if it was really parsing the xml files to find the end of the
document. At the moment it doesn't hit apt-rpm.

> >> 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.
== Design flaw.

Ralf