On Sat, 20 Aug 2011 07:16:25 +0200, RC (Ralf) wrote:
> On 08/19/2011 11:45 PM, Göran Uddeborg wrote:
> > Michael Schwendt:
> >> Do you parse them all without testing?
>
> I sense a misunderstanding.
>
> People seem to presume rpm.specs to be written in a "well defined
> programming language" using a lexical scanner and parser underneath.
To clarify my use of the term "parse" above, what I meant is the human
parser. Whether the reader of the spec file is able to _recognise_ a macro
easily/immediately. Especially in situations where they are surrounded by
non-space characters. Brackets not only aid the human reader but also the
machine that substitutes macros with their values. Or the editor that
applies syntax highlighting.
> This does not apply, the "rpm.spec language" is a "macro language",
> similar to regexes and m4, using macro sets underneath, similar to
> autoconf or sendmail, with all kind of ambiguities and "historic
> heritage and historic heuristics" underneath.
>
> I.e. rpm doesn't actually "parse" spec files in the sense
> compilers/interpreters would parse/interpret a well "defined language",
> it expands macros and passes the results to other parties.
What constitutes a macro? What is the grammar? If we restrict ourselves
to using only a subset of the possible expressions that build macro names,
we can avoid errors and increase readability.
Since you talk about "ambiguities", those commonly lead to bugs with
poorly named variables in programming languages, too, not just RPM spec
files.
In a sufficiently large spec file with more than the default set of
macros, it isn't obvious whether %name2 is expected to be %{name}2 instead
and what lib%name_* is meant to match. rpmbuild wouldn't complain. Unexpanded
macros have lead to errors in packages before. Mixed macro usage like
%version and %ver has been seen before, too, a pitfall when replacing %ver
with something else and either messing up %version or forgetting a single
%{ver}.
Btw, do you agree with making explicit brackets a SHOULD?
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
