On Fri, Dec 28, 2007, Ralf S. Engelschall wrote:

> Ok, from the CLI the new macro stack expansion now works just fine and
> as expected:
>
> | openpkg rpm --define "foo foo" --define "foo bar" --define "foo quux" --eval '%{@foo:,}'
> | foo,bar,quux
>
> But from a .spec file the first value is now missing:
>
> | [...]
> | BuildPreReq:  foo
> | BuildPreReq:  OpenPKG, openpkg >= 20050726
> | BuildPreReq:  binutils
> | BuildPreReq:  make
> | PreReq:       OpenPKG, openpkg >= 20050726
> |
> | %{lua: io.stdout:write(rpm.expand("%{@buildprereq:, }") .. "\n") }
> | [...]
>
> The output is:
>
> | $ /openpkg/bin/openpkg rpm -bb *spec
> | OpenPKG, openpkg >= 20050726, binutils, make
>
> Notice that "foo" is missing.
>
> So, there remains at least one subtle bug related to the first macro
> value (at the bottom of the stack). Previously for the CLI scenario this
> value was output twice, now the CLI scenario is correct, but in .spec
> file parsing the first value now is missing.
>
> So, although all other issues are now gone, we still have this
> small little bug...

Ok, found the problem: the --define option in 2002 was changed to do
something very strange: when it is the absoluteley first option on
the command-line the --define "foo bar" is actually implemented as it
would be a --prefdefine "foo bar" --define "foo bar" and hence on the
macro stack buttom the "foo" is there twice. I don't know why this
strange behaviour was implemented, but I think we should get rid of it
at all: 1. it is confusing, 2. it applies only to the absolutely first
occurrence of a --define, 3. there is already the explicit --predefine
in case one really has to define a macro before the config files are
loaded. So, I now applied the following patch which fixes the remaining
issues. With it both the CLI and .spec scenarious are now working
correctly.
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com