Closed #1149.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1149#event-4324748371___
Rpm-maint mailing list
Rpm-maint@lists.r
I guess the overall direction of rpm development is to rather add more lua than
adding more to the macro language. So I am closing this here as this is not
likely to happen any time soon... well any time actually.
--
You are receiving this because you are subscribed to this thread.
Reply to thi
That would be awfully nice. The more native elements (macros variable tags) can
be manipulated/set/unset from lua, the less we need to worry about the legacy
rpm tangle. I don’t think anyone wants to write and maintain complex logic
using the native rpm macro language, it’s just that pushing dat
That said, I'm thinking more about further blurring the line between %{lua:...}
and the native rpm macro subsystem. For example, could we expose Lua tables
(and/or other variables) as native macro elements.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
There are no *variables* in rpm. There are only macros, and %{lua:...} is
nothing more, nothing less than a means to generate macro content
programmatically.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.co
It’s not a lua vs non-lua thing. I’m an heavy lua user myself. I expect that
this feature would unlock more lua use, not less.
While very cool and useful, lua is ultimately limited by the stage at which lua
expressions are evaluated. So, no matter how much lua you add to a spec, you
need, at so
Macro arrays would be useful every now and then, yes.
OTOH by the time you need arrays you typically need loops and the like, which
is what we have Lua for. I'm not saying "no" to this but in general I rather
put an effort into making Lua more usable in macros than implement new things
in the m
