On Nov 11, 2008, at 2:03 AM, Ralf S. Engelschall wrote:
>>
>> I dunno what the final answer for lua internal will be, there is a
>> balance point
>> there somewhere, I just don't know where the point lies yet.
>>
>> Other ideas?
>
> For OpenPKG I decided to drive RPM 5 always with Lua and because of
> lua/local/* stuff I decided to always build the internal Lua...
>

Well, as a "vendor", you are entirely empowered to make the decision to
"always build internal lua".

 From an RPM engineering POV,
	#ifdef	WITH_LUA
means that every RPM implementation must be prepared to live without  
LUA.

That is a rather drastic alternative choice that blocks RPM itself  
from using lua
in any meaningful way imho.

Adding a 1-line test in "make check" to validate the output of a  
":yaml" query format
extension as
	yaml.load_file("test.yaml")
in order to start using YAML to deliver RPM package metadata for use  
by applications
becomes a hugely complicated exercise in portability: linking,  
loading, compiling
and auto-configuration must all be prepared to deal with all the  
alternative choices.

The attachment point of internal lua through -lrpmmisc is currently  
causing a SELinux
security pop-up regarding "potential buffer overrruns" on every  
invocation of rpm if
any symbol in any RPM library (other than -lrpmmisc) is used within  
lua/local.c code.
If linking with -pie, the text area is RO, and the lack of strict  
forward linkage in libraries forces a
write to the RO text segment triggering the SELinux pop-up with its  
Draconian warning of dire
consequences of "potential buffer overflows" if rpm5 is invoked on  
Fedora (and likely RHEL and CentOS).

Well once the root cause (and rules) are understood, there's certainly  
engineering solutions
available, including not using -pie, or ensuring that forward linkage  
always exists, or
extending lua (as designed) within -lrpmio, or (as you have done) with  
additional
lua modules in -lrpm. Those aren't really the hard issues, dealing  
with the tyranny of
the alternative choice of
	#ifdef	WITH_LUA
opt-out is what is hardest to figure.

Again,

>> I dunno what the final answer for lua internal will be, there is a
>> balance point
>> there somewhere, I just don't know where the point lies yet.

And I'd dearly like to be able to just use -lsyck and -lxmlrpc_c  
through LUA without
reintroducing a thundering cancerous snarl of portability issues into  
RPM, or
having to add Yet More API's.

73 de Jeff