On Sep 5, 2008, at 1:52 AM, Alexey Tourbin wrote:
> On Thu, Sep 04, 2008 at 05:08:21PM -0400, Jeff Johnson wrote:
>>> Also, it is necessary to provide lua bindings for 1) retrieving
>>> headers by instance, perhepas something like "h = getAddedHeader
>>> and "h = getRemovedHeader(num)"; and 2) retrieving header entries,
>>> e.g. "h.filenames".
> BTW, back in 2005 I wrote a file luarpm.c, which is lua bindings to
> akin to old Perl-RPM. I don't remember much details, but perhaps
> it was
> for lua-5.0, and perhaps it even worked.<luarpm.c>
The bindings look useful.
(aside) Personally I'd like to see a parameterized match iterator rather
than methods like
static int luaRPM_db_whatrequires(lua_State *L)
return db_find(L, RPMTAG_REQUIRENAME);
that hide the parameter. The reason is that per-index methods
prevent extending or otherwise changing the underlying db store, and the
parameter can often be hidden by wrapping in the native binding language
rather than locked into the C glue layer, permitting application
to create their own API's.
(another aside) I'd also rather see the bindings tied through a rpmts
object rather than a rpmdb database object. Verifying signatures of
in the database requires a keyring store, and there are other issues
exclusive/shared locking side effects that need more context than is
provided by a
rpmdb database object alone. Most applications are not very well
to make decisions regarding global locking strategies, or pubkey
The luaRPM_hdr_tag() binding can be vastly simplified, the tagtable
the usual data type and scalar/array attributes that should be used
of the implicit tag typing in the huge switch.
Some of the coercion to strings should be done generally, not in the lua
But overall your lua bindings have implemented the most important
sine qua non
match iterator sufficiently to be useful.
Shall we add to rpm-5.x?
73 de Jeff
Received on Fri Sep 5 16:11:38 2008