I gave you some hints already, I'm not going to spell it all out for you, why
don't you think about it by yourself a bit?
It'd indeed be trivial to implement, and looks like an easy solution to a
common problem on first sight, but in the bigger picture such an operator would
be harmful to rpm
Closed #820.
--
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/820#event-2578624539___
Rpm-maint mailing list
Rpm-maint@lists.rpm
> Please, how does it break the stack semantics?
I am asking because I think that it is easy to implement such a builtin macro.
E.g. popMacro() can be changed such that it returns 1 if an macro was deleted
and 0 if no macro was deleted. After that it will be easy to call popMacro() in
some funct
Please, how it breaks the stack semantics?
--
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/820#issuecomment-523881821___
Rpm-ma
The thought has crossed my mind too, but there's a reason such a thing is not
implemented: it breaks the stack semantics, which various parts of rpm rely on.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.co
A builtin macro
```%undefine macro_name```
removes the last defined _'macro_name'_ from defined macros. But it still
leaves all older definitions of the macro _'macro_name'_. So as @pmatilai wrote
in #115 - "macros stack so undefining doesn't guarantee said macro actually
goes away".
Thus I
