[Rpm-maint] [patch 1/2] exposing macros to scriptlets and bindings as a dictionary.

Panu Matilainen pmatilai at redhat.com
Tue Nov 13 09:35:42 UTC 2007

On Fri, 2 Nov 2007, Peter Jones wrote:

> This patch exposes a copy of the current set of defined macros to python and 
> lua as a dictionary and a table, respectively.  The next patch will add 
> fairly simple macros %patches and %sources to macros.in .

Sorry I haven't commented on this earlier...

Seems I broke this patch by removing the macro struct internals from the 
API the same day you sent this, timezone differences make it a bit hard to 
tell which happened first :)

I can see having %patches (and why not %sources too) being useful, one 
possibility being something like %applypatches macro to apply all patches 
(which is what you normally do anyway) instead of 

Implementation-wise... we'll need to add an API for accessing the macro 
structures, I'm not going to re-expose the internals [*].

While at it (for python at least), I think we might as well make the macro 
system look like a normal dictionary. Eg to define a macro, you'd use 
'rpm.macros["foo"] = value' etc, instead of requiring special getMacros(), 
addMacro() etc methods.

Also I'm not too enthusiastic about adding the findmacros() etc Lua-stuff 
to global init.lua when most of it is only ever useful in build. Maybe add 
a separate initbuild.lua that gets loaded only on rpmbuild (or from 
librpmbuild) - I've been thinking of splitting out all sorts of bits of 
rpm configuration into separate build vs core config (the average rpm -Uvh 
type use needs very little configuration, the build is the config-heavy 

[*] The bigger picture is that I'm working towards making rpm-python 
buildable as standalone instead of being tied to core rpm, for several 
- I think language bindings should under no circumstances have, or need, 
access to rpm library internals. The public API needs enhancing / fixing 
instead where necessary.
- Development of language bindings shouldn't be tied to rpm development 

 	- Panu -

More information about the Rpm-maint mailing list