@jasontibbitts yes, it's been going on a lot recently, see
https://github.com/rpm-software-management/rpm/issues/551#issuecomment-425060771
@n3npq, repeatedly posting and then deleting your comments is disruptive and
abusive behavior and continuing to do so even after being warned just earned
@jasontibbitts: %luamacro would need to be implemented as a co-routine because
of rpm's embedded lua interpreter has a persistent global environment.
That is very different than shell code, where a sub-shell inherits but cannot
change its parent's environment. With rpm+lua, all lua invocations
Indeed, that's pretty much completely unpossible. Though if %luamacro takes no
arguments and expands to shell code then of course that works to some degree.
It may even work as you want to work. You just have to be very careful about
where the line breaks are in the emitted shell code.
--
The shell script and Lua macros exist in two entirely different domains that
execute at equally different times. You're asking that bash somehow call back
into rpm internals. Good luck with that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Closed #556.
--
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/556#event-1876850556___
Rpm-maint mailing list
A rather annoying "feature" of the current lua integration is that the lua code
is evaluated before executing any rpm section
So if you provide a lua macro that does not blindly pass arguments somewhere
else, but does some test or processing on them
```specfile
%luamacro somevalue
```
will