[Rpm-maint] [rpm-software-management/rpm] RFE: Do-what-I-mean semantics for macros in spec comments (#158)

[Panu Matilainen]

Macro expansion in spec comments continues to baffle and irritate users year after year after year. And no wonder, since it's all so wonderfully inconsistent: commenting works fine in many cases that appear to be macros (but are not, really) but then behave unexpectedly in others. And as of recently, you get warnings for some of them (but not all), often needlessly.

There are various legitimate uses for expanding macros in what *appear* to be comments such as creating content, eg:
```
%build

cat << EOF >> fooscript
#!%{_bindir}/python

... do stuff ...
EOF
```
I'd be surprised if there aren't packages that are actually relying on this, and at least to me this seems perfectly sensible, so we don't really want to disable macro expansion in comments. The pain points, AFAIK, are:
- expansion of multiline macros 
- %define, %global and %undefine in comments

There have been various patches to turn macros in comments into errors (eg PR #123) but that just doesn't make any sense at all: why should commenting out line X be *forbidden*? Rpm should really just do the right thing , and do it consistently everywhere. The right thing basically being: expand what you can without side-effects. Something like:
- For commented-out multiline macros, make the entire expansion commented-out, one way or the other. One way is simply replacing newlines with spaces, another one is inserting #'s after the newlines.
- Macro definitions could quite easily be disabled by adding a "readonly"-mode to the macro engine (I have a PoC patch to do just that, it's quite trivial except for %{lua:...}) Now, it's technically possible that somebody is actually *relying* on the existing, longstanding behavior of %define's taking action in comments (at least somebody has consistently brought this up whenever this discussions reprises), so maybe it should be made configurable, but default to what 99% of users expect.
- Shell-expansion can have side-effects so it should be disabled too, unfortunately. 
- %{lua:...} could probably be tamed into a safe mode but in it's current form it'd need to be disabled
- For the shell and Lua-cases, it'd be neat if they too could be expanded by executing in a readonly environment, perhaps that could be achieved with seccomp or such. Also wondering if there should be an additional "noexec" macro engine flag to control shell/lua.

Anything else? Thoughts, comments?

-- 
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/158
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170217/f4c83c99/attachment.html>