[PATCH] Warn when macro options evaporate silently

[Panu Matilainen]

On 01/22/2013 01:20 AM, Alexey Tourbin wrote:
> In the %name form, when the name is invalid or when the macro does
> not exist, a silent fall-back is provisioned to as-is substitution.
> On the contrary, the %-o form has %?name semantics, that is, implies
> an existent test.  Hence at the top level, i.e. in specfile sections,
> options always evaporate silently.  Given the ambiguity of the %-o form,
> this deserves a warning.

Here too, nothing against the idea. Just wondering whether it should be 
turned into a downright error as technically the %-o form can be 
considered a syntax error outside parametrized macro expansion, such as 
spec toplevel.

The same could be applied to the other parametrized macros too I guess, 
all the special %[0-9], %*, %** etc macros are meaningless outside the 
parametrized macro expansion.

> For example, the following line found in FC18 xfce4-taskmanager.spec:
> - Add patch to fix 0%-CPU bug
> gets actually expanded to:
> - Add patch to fix 0PU bug

Pooh... this and the other similar Fedora examples seem like somebody 
found a "clever" way to avoid warnings from rpmlint or other similar 
checker. How writing %-doc is supposed to be easier than the %%doc is 
beyond me though.

> This will now produce the warning:
> warning: %-CPU parsed as %{-C}PU

Might as well state the fundamental reason for the warning (or error, if 
we want to go there): option macro used in invalid context.

	- Panu -