RPM Community Forums

Mailing List Message of <rpm-users>

Re: RPM5 and YML-like Specfiles

From: Jeff Johnson <n3npq@mac.com>
Date: Sun 10 May 2009 - 22:16:22 CEST
Message-id: <E722F3A3-D249-41EE-98A7-832073681840@mac.com>

On May 10, 2009, at 4:01 PM, Eric MSP Veith wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 10 May 2009, Jeff Johnson <n3npq@mac.com> wrote:
>> But there's no reason whatsoever why conversions to alternative
>> format/syntax cannot be attempted.
>
> Well, what will the future grammar of *.spec files be? I'm just  
> eager to
> adopt features of newer RPM versions, since I never used the old  
> Versions
> before and do not have to deal with inherited waste. And RPM is much  
> more
> useful when it does not have to emulate old behaviour.
>

 From a grammatical POV, here are the major flaws with existing spec  
files:

	1) there's no return to the preamble (i.e. Name: foo)
	parsing once left. This essentially prevents spec files from
	being nested.

	2) there's no explicit end marker for sections like %post,
	the start of the next section marks the termination of
	the previous section. Which is perfectly OK until you
	want comments attached to the next, rather than the previous,
	section. Adding a "%}" token would not be hard, nor is
	it very hard to reassociate comments with sections.

	3) the scoping of %if across %prep etc section markers is insane.
	Its entirely possible to write a spec file using a %if construct
	that ends up merging %install into %prep. The right thing to do
	would be to force %if constructs within %prep etc section scoping. But
	everytime I've suggested I get drowned with "How dare you do that!"
	noise, so I've largely given up.

But there's really no need for much of a grammar, if one views the
contents of a spec file as data. How the data is to be used is
out of scope for markup, and what the markup looks like, are very
different issues that are confused in rpmbuild solely because its
not a proper parser.

"proper parser" == no side effects.

rpmbuild has some devilishly sneaky side-effects currently,
including recursing (and restarting the parse) when
	BuildArchitectures: noarch
is encountered, as well as various hacks to test source/patch
existence (and fetch if missing) that should not be done in
what I'm calling a "proper parser".

73 de Jeff
Received on Sun May 10 22:16:46 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.