On Oct 25, 2008, at 11:34 PM, Jeff Johnson wrote:

> Robert Scheck pointed out that I managed to break internal lua  
> Friday night.
>
> The symptom looks like this:
>
> error: Lua script failed: [string "./local/lom.lua"]:24: module  
> 'lxp' not found:
>        no field package.preload['lxp']
>        no file './lxp.lua'
>        no file '/usr/local/share/lua/5.1/lxp.lua'
>        no file '/usr/local/share/lua/5.1/lxp/init.lua'
>        no file '/usr/local/lib/lua/5.1/lxp.lua'
>        no file '/usr/local/lib/lua/5.1/lxp/init.lua'
>        no file './lxp.so'
>        no file '/usr/local/lib/lua/5.1/lxp.so'
>        no file '/usr/local/lib/lua/5.1/ 
> loadall.so'popt-1.13-4.fc10.i386
>

Yup I totally screwed up adding additional internal lua modules so far.

> There's at least two issues there.
>
> 1) the _G paths in lua likely should be made rpm specific, perhaps
>    /usr/lib/rpm/lua
> although lua makes a sharper distinction between moudule.lua scripts
> (in /usr/share/lua/5.1) and compiled module.so (in /usr/lib/lua/5.1)
> so one /usr/lib/rpm/lua may not be sufficient.
>

Adding additional "bog standard" lua modules to extend rpm's internal  
lua
is far from easy atm. There's custom crafted code in lua/local, rpmio/ 
rpmlua.c, and even in
lib/rpmluaext.c currently.

I'd like to see it become easier to extend internal lua in rpm, in  
order to
add rpm specific modules, include system specific components, or  
(oossibly, I
personally loathe envvars) support user peculier LUA_INIT, LUA_PATH,  
and LUA_CPATH.

LUA itself uses
	#define LUA_ROOT	"/usr/local"
as the starting prefix for searching for modules and/or DLL's
	#define LUA_LDIR	LUA_ROOT "/share/lua/5.1"
	#define LUA_CDIR	LUA_ROOT "lib/lua/5.1"

Note that the distributed "/usr/local" is not appropriate for
chasing system or rpm specific lua extensions. Sure /usr/local  
"works", just
useless imho.

For system specific extensions
	#define SYSLUA_ROOT	"/usr"
and for rpm specific extensions
	#define RPMLUA_ROOT	USRLIBRPM "/lua"
would seem to make sense, with the rest of the subdir
structure identical. (aside) rpm specific extensions
don't really need a version in the path, but the regularity
is more predictable than removing. The duplicated "lua"
in the path is annoying as well. Perhaps RPMLUA_ROOT
should not have "lua" as a subdir.

I've written the above using C #defines, but rpmio/rpmlua.c
already has overrides to achieve RPMLUA_ROOT (but without
the lua conventional substructures). AFAICT from reading
rpmio/rpmlua.c, the currently implemented extension location
(yes, singular, and again using C #define terminology)
	#define	RPMLUA_LDIR	RPMLUA_ROOT "?.lua"
with no ability to find/load DLL's, which is likely as simple as
	#define	RPMLUA_CDIR	RPMLUA_ROOT "?.so"
Searching modules in subdirs, adding a version in path and perhaps
different paths for modules (aka *.lua) and DLL's (aka *.so) might
be needed.

(aside) in lua-speak, the '?' represents the module name being  
searched for.

There is also another initialization customization in rpmio/rpmlua.c  
similar
to how macro files are loaded. Each of the colon separated files,  
including
globs, in
#define RPMLUAFILES "/usr/lib/rpm/init.lua:/usr/lib/rpm/rpmlua:/usr/ 
lib/rpm/%{_target}/rpmlua:/etc/rpm/rpmlua.*:/etc/rpm/rpmlua:/etc/rpm/% 
{_target}/rpmlua:~/.rpmlua"
is loaded.

Is that amount of "flexibility" really useful or needed? Sure the  
mechanism mimics
how macros are loaded. OTOH, macros are peculier to rpm and lua has  
other conventions
for extending that are quite different from rpm macros.

OTOH, the /usr/lib/rpm/init.lua script is the perfect place to change
paths to search what I have been calling SYSLUA_ROOT and RPMLUA_ROOT.

Ralf: OpenPKG is likely the only user of the RPMLUAFILES mechanism.  
The mechanism
hurts little if carried forward, but perhaps "bog standard" lua  
conventions should be done
instead because simpler and less surprising. Another gain is that  
large parts of
rpmio/rpmlua.c might be extended and included for use by system lua.  
That of course
is a very different goal than embedding lua into rpmlib itself.

Now that I have studied the current implementation sufficiently, I  
will likely
try a different approach to add lua xmlrpc support to rpm than adding  
Yet More Glop
to the lua subdirectory. Using init.lua to change global search paths  
to include
system installed modules is sufficient for my prototyping purposes.

I will also attempt the lsyck lua binding as a /usr/lib/rpm/lua/ 
lsyck.so DLL to
avoid recreating a cancerous snarl of AutoFu all over again.