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 -
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
