[Rpm-maint] [rpm-software-management/rpm] Unclosed %if (when defined inside %define) (#1198)

Michal Domonkos notifications at github.com
Fri Jul 17 12:26:37 UTC 2020


This issue stems from the fact that the line continuation marker `\` has *different* semantics in the spec-level context and in a macro definition. On the spec level, it is used to break long `%if` statements into multiple lines. Inside macro definitions, it's the whole body that's broken down. The patch in 5f4fdce interprets these markers equally, though.

This becomes a problem when a `%define` or `%global` macro is encountered in a false branch of an `%if` statement and is therefore left unexpanded (for obvious reasons); the spec parser just continues scanning the macro's body as if it were part of the spec itself: it joins the inner `%if` statement into a single line, including the inner `%endif` (since all of the lines end with an `\`) and finally tries to match it against a corresponding `%endif`, which fails as there's none.

The remedy here would be to completely skip the macro's body in case it's unexpanded. In fact, there's a very simple and elegant (yet non-obvious) way to do this: when joining multi-line `%if` conditionals, treat `%define` as a such a conditional; that way, the whole macro (when unexpanded) collapses into a single line and its content is not interpreted. I have a working patch here: https://github.com/dmnks/rpm/commit/9c1c592d40777868d672a531b49c63fb6dd6ec84

That being said, it turns out that conditionals inside macros are *unsupported*. The macro expander does *not* interpret them at all. For example, the following construct would print "hello":

```
%define test() \
%if 0 \
%{echo:hello} \
%endif

%test
```

This is also mentioned (though not entirely clearly) in the `/doc/manual/spec` file:
```
%if-conditionals are not macros, and are unlikely to yield expected results
if used in them.
```

@ignatenkobrain, is there a specific use case for such conditionals that I'm missing? While there is a simple fix for this (as described above) which shouldn't introduce any side-effects (but I am not 100% sure yet), it doesn't make much sense to apply it if the use case being fixed is in fact unsupported.

-- 
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/1198#issuecomment-660079015
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200717/b6985836/attachment.html>


More information about the Rpm-maint mailing list