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

[Peter Jones]

Panu Matilainen wrote:
> 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 %patch0
> %patch1
> ...
> %patchX
> 
> Implementation-wise... we'll need to add an API for accessing the macro 
> structures, I'm not going to re-expose the internals [*].

Fair enough.

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

I'm not necessarily opposed to this, but it does leave the interface a 
little clunky.  How do you set/change flags on the macro?  Or do you not 
want to expose them at all?

> 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 part)

Yeah, that's pretty reasonable.

> [*] The bigger picture is that I'm working towards making rpm-python 
> buildable as standalone instead of being tied to core rpm, for several 
> reasons:
> - 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.

Absolutely.

> - Development of language bindings shouldn't be tied to rpm development 
> cycles.

Don't know that it really makes much difference, but ok, that's fine ;)


-- 
   Peter