On 10/08/2013 07:48 PM, Bob Bell wrote:
Is no one able to help with this issue? :(
Sorry I thought I already replied to this (I do remember starting a
reply) but obviously not...
On Mon, Sep 09, 2013 at 03:25:05PM -0400, Bob Bell wrote:
I've been bumping up RPM macro/spec sophistication recently, and one
thing I'm trying to do is to call one parameterized RPM macro from
another parameterized RPM macro. I'm seeing some behavior that's ...
less than helpful.
As a real quick summary, here's what I'm seeing:
1. When I call the second macro, %# and %* are set, as are the
positional parameters (%1, etc.) for anything that's been set, but
positional parameters that haven't been passed in remain set from the
previous macro invocation (i.e., the "parent" invocation)
2. When I pass parameters via named flags to the second macro, any
existing flags remain set. This is true even if the second macro
takes the same parameters, but I don't pass them, which is
particularly troubling.
This makes it really hard (almost impossible?) to determine what
parameters were actually pass to the second macro. For example,
1. If the second macro can take, say, either one or two parameters, I
cannot reliably use %{?2} to check if a second parameters has been
passed. I need to check to see if %# == 2 first, because %2 might be
set from another macro that's been invoked.
2. If the first and second macro both take a flag (say, "-f"), but
the same flag isn't passed as a parameter to the second macro,
it's pretty much impossible to tell, because %{-f} (and its variants)
will still be set from when the first macro was invoked.
Can someone clarify what the behavior SHOULD be? Is this a bug?
Should I be doing things differently?
Lets just say the above description matches what I would expect from the
current implementation. That doesn't make the behavior any more sensible
of course.
Here's my test ~/.rpmmacros file that I'm using to explore RPM's
functionality:
%bar(x:y:z:) \
%{lua:io.stderr:write(rpm.expand("%#") .. " arg(s) to " ..
rpm.expand("%0") .. " = " .. rpm.expand("%*") .. "\\n")} \
%{lua:io.stderr:write("1 == " .. rpm.expand("%1") .. "\\n")} \
%{lua:io.stderr:write("2 == " .. rpm.expand("%2") .. "\\n")} \
%{lua:io.stderr:write("-x == " .. rpm.expand("%{-x}") .. "\\n")} \
%{lua:io.stderr:write("-x* == " .. rpm.expand("%{-x*}") .. "\\n")} \
%{lua:io.stderr:write("-y == " .. rpm.expand("%{-y}") .. "\\n")} \
%{lua:io.stderr:write("-y* == " .. rpm.expand("%{-y*}") .. "\\n")} \
%{lua:io.stderr:write("-z == " .. rpm.expand("%{-z}") .. "\\n")} \
%{lua:io.stderr:write("-z* == " .. rpm.expand("%{-z*}") .. "\\n")}
%foo(x:y:) \
%{lua:io.stderr:write(rpm.expand("%#") .. " arg(s) to " ..
rpm.expand("%0") .. " = " .. rpm.expand("%*") .. "\\n")} \
%{lua:io.stderr:write("1 == " .. rpm.expand("%1") .. "\\n")} \
%{lua:io.stderr:write("2 == " .. rpm.expand("%2") .. "\\n")} \
%{lua:io.stderr:write("-x == " .. rpm.expand("%{-x}") .. "\\n")} \
%{lua:io.stderr:write("-x* == " .. rpm.expand("%{-x*}") .. "\\n")} \
%{lua:io.stderr:write("-y == " .. rpm.expand("%{-y}") .. "\\n")} \
%{lua:io.stderr:write("-y* == " .. rpm.expand("%{-y*}") .. "\\n")} \
%{expand:%%{bar %{-x} %{-y:-z} %{-y*} bararg}}
And here's the results I've seen that lead to my conclusions:
# rpm --eval '%{foo -x A -y B fooarg1 fooarg2}' >/dev/null
2 arg(s) to foo = fooarg1 fooarg2
1 == fooarg1
2 == fooarg2
-x == -x A
-x* == A
-y == -y B
-y* == B
1 arg(s) to bar = bararg
1 == bararg
2 == fooarg2
-x == -x A
-x* == A
-y == -y B
-y* == B
-z == -z B
-z* == B
My primary test bed has been SUSE Linux Enterprise Server 11 SP2,
running rpm 4.4.2.3 (with SUSE patches, no doubt). I'm confirmed the
same behavior on an Ubuntu machine with rpm 4.9.1.1.
As Robert already pointed out, with existing releases your best hope is
to use different flags to disambiguate & use %# to determine number of
arguments. Or try to arrange the macros differently to avoid the issue.
Thanks for the detailed report and reproducer though, one of these days
I might take a look at what it would take to make the local arg macros
scope correctly.
- Panu -
Thanks in advance for your assistance,
Bob
P.S. I'm not currently subscribed to this mailing list, so please
include me on any replies.
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
