[Rpm-maint] [patch 1/2] exposing macros to scriptlets and bindings as a dictionary.
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