First off, thanks for the patch. You're one of
mebbe 5 people (Gustavo, in ~2003, was the previous
person, on a similar Conectiva vendor induced bug
squashing mission) who might understand what I'm about to say. ;-)

The code in parseSpec.c is thoroughly rotten.

First of all, when originally written, the spec parser reads
line-by-line because of the general uglix truism that data size was  
often bigger
than code size.

The first hack was to add %iffoo to skip input lines. Not too shabby,  
just ...
do we really have to?

Then someone else (I forget who) decided that it would be really cool
if spec files could be split into pieces, and wrote a stack for spec  
file
components. To this day, I've never seen _ANY_ usage case for
nested spec file input streams.

Then came macros, adding an expansion layer onto the mess.
Unlike most macros languages, rpm spec files have separate
line-by-line %if logic and streaming macro expansion. That mess was  
complicated
and twisted enough that this was the macro usage rule for spec files:

	Macros are expanded _EVERYWHERE_, on the false branch of %if
	handling, embedded in tokens or within quoted strings, _EVERYWHERE_.

Gustavo decided to fix %define's on the false branch of %if, adding the
nifty state machine.

And now you have ensured that a multiline macro expansion at the
end of a spec file expands correctly.

So the entire code mess is considerably larger and entirely pointless.

I'm almost certain that I can write some macro expansions with included,
say, hidden "%elif" or delayed "%%define"  that will easily break the  
existing
spec parser.

All this code is embarassing crap is what I'm saying. That's a  
design, not an
implementation, flaw.

BTW, yr patch appears to have broken nothing. Thanks for the patch!

73 de Jeff