On Tue, Jan 22, 2013 at 6:39 PM, Panu Matilainen
<pmatilai@xxxxxxxxxxxxxxx> wrote:
> 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.
I think that there must be a distinction between syntax and semantics,
i.e. between the parser and the interpreter, although there are
already some signs that the distinction is not very rigorous. Anyway,
this patch was made in the "syntactic mood": report on ambigous syntax
with unintended consequences. Note that this change does not warn on
the %{-o} form, since it is not syntactically ambiguous. The parser
then assumes the user knows what he is doing.
> 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.
But specfiles can have URLs with pieces like%20this. And since there
is no %20 argument at the top level, the as-is substitution will
silently do the right thing. So is it worth to break otherwise
legitimate packages? Probably not. On the other hand, %{20} in
(toplevel) specfile sections looks more wrong exactly because it is
unambiguous.
> Might as well state the fundamental reason for the warning (or error, if we
> want to go there): option macro used in invalid context.
So perhaps indeed it is better to produce the same warning for both
%-o and %{-o} and reframe it from a non-syntactic point of view.
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
