On Oct 26, 2008, at 1:08 PM, Jeff Johnson wrote:

>
> 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.
>

The problem trigger for LUA_ROOT defined as /usr/local was my brain  
fart.
However the issue is potentially a problem.

When byte compiling lua/local/lom.lua for direct inclusion in local/ 
llocal_lua.c,
I failed to notice
	-- $Id: lom.lua,v 1.1 2008/10/24 22:25:45 jbj Exp $
	require "lxp"
That's OK if I had been smart enuf to realize that rpmio/rpmlua.c also
needed to have
	#include <lxplib.h>
	...
	{"lxp", luaopen_lxp},
added to resolve the requires "lxp" module load.

The (potential) flaw is that there is a pathway through the
internal lua code that depends on LUA_ROOT value being set
reasonably __BEFORE__ the custom rpm lua internal initialization
can occur by reading
	/usr/lib/rpm/init.lua
Sure that flaw can be lived with ...
	
> 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 changed LUA_ROOT to what I'm calling SYSLUA_ROOT
conditioned on __linux__
	#if defined(__linux__)
	#define LUA_ROOT        "/usr/"
but there's almost certainly more thought about portability
and precedence in searching that will be needed.

I've also added code to print out LUA specific info
	$ rpm --showrc
	...
	LUA MODULES:
	luafiles              : /usr/lib/rpm/init.lua:/usr/lib/rpm/rpmlua:
	/usr/lib/rpm/i386-linux/rpmlua:/etc/rpm/rpmlua.*:/etc/rpm/rpmlua:
	/etc/rpm/i386-linux/rpmlua:~/.rpmlua
	luapath               : /usr/lib/rpm/lua/?.lua
Exposing the lua initialization should help discovering how to extend  
rpm using lua.

(aside) Hmmm, time to get lua _VERSION added to --showrc spewage too.

<snip>

>
> 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.
>

Hmmm, I still think the default script files need to be simplified:
1) init.lua should be moved into the lua specific tree.
2) there are both "rpmlua" and "lua" naming conventions, either is  
better
than both.

> 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.
>

There appear to be LUA 5.1 conventions to pull in internal modules &  
DLL's,
judging from the failed searches I'm seeing for "loadall.so" that might
be better used than /usr/lib/rpm/init.lua. OTOH, conventions are easy
to change when the reasons for the conventions are better understood.

> 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.

My primary goal in looking at lua is to attempt to access opendht.org.

There are two ways to do that: XMLRPC and SUNRPC.

SUNRPC is rather easier, so I'm trying the "politically correct" but  
harder
path first, everyone hates SUNRPC nearly as much as they hate Berkeley  
DB.

Wrestling with internal/external C libraries by linking xmlrpc_c (that
appears best-of-breed to me, but there are other C libraries for XMLRPC)
gets harder and harder with rpm code.

So instead of C, I'm attempting access using lua xmlrpc. I'm hoping
that, with a little work on external module/DLL loading conventions,
and some likely useful internal refactoring of rpmio/rpmlua.c, that
I can avoid the deadly AutoFu necessary when handling openssl
(or gnutls or nss or ...) and the usual expat <-> libxml2 chasing.

To achieve access to opendht.org rpm needs to load these modules
	lxplib
	socket
for XMLRPC access, and
	lcrypto
in order to be able to calculate SHA1 digests needed for retrieval keys.

I hope that clarifies what and why I'm hacking on LUA.

Ralf: I tried this patch to add -I.../lua/socket to CFLAGS:

Index: configure.ac
===================================================================
RCS file: /v/rpm/cvs/rpm/configure.ac,v
retrieving revision 2.318
diff -u -b -B -w -p -r2.318 configure.ac
--- configure.ac	19 Oct 2008 07:46:48 -0000	2.318
+++ configure.ac	27 Oct 2008 12:29:10 -0000
@@ -1144,7 +1144,7 @@ USE_LUA_CHKCONFIG=no
  RPM_CHECK_LIB(
      [Lua], [lua],
      [lua], [lua_newstate], [lua.h],
-    [no,internal:external:none], [lua:local],
+    [no,internal:external:none], [lua:local:socket],
      [ if test ".$RPM_CHECK_LIB_LOCATION" = .internal; then
            AC_CHECK_LIB(m, fabs)
            AC_CHECK_LIB(dl, dlopen)

Should that have "worked"? Instead I'm seeing this (in rpmio/Makefile)

WITH_LUA_CPPFLAGS =  -I$(top_srcdir)/$(WITH_LUA_SUBDIR)/local -I$ 
(top_builddir)/$(WITH_LUA_SUBDIR)/local -I$(top_srcdir)/$ 
(WITH_LUA_SUBDIR) -I$(top_builddir)/$(WITH_LUA_SUBDIR)

i.e. 2 "local"s and no "socket" subdir added to include paths.

No biggie, luasocket external, not internal, is where I want to end-up,
so there's no dire need for multiple include subdirs using RPM_CHECK_LIB

hth

73 de Jeff