Created attachment 138213 [details]
log from "rpmlint iptables-1.3.5-1.2.i386.rpm > rpmlint-iptables"

Created attachment 138214 [details]
rpmlint iptables-1.3.5-1.2.i386.rpm > /tmp/rpmlint-iptables 2>&1

Now, the correct log ;)

The cause seems to be the iptables package containing this construct below in 
/etc/rc.d/init.d/iptables:
...
IPTABLES=iptables
...
VAR_SUBSYS_IPTABLES=/var/lock/subsys/$IPTABLES
...

The shell_variable expansion code intThe syssys check in
/usr/share/rpmlint/InitScriptCheck.py (near line 135 in rpmlint-0.78-1.fc5.1)
doesn't seem to able to correctly expand $IPTABLES in
VAR_SUBSYS_IPTABLES=/var/lock/subsys/$IPTABLES

and recurses into an infinite recursion.

Created attachment 138221 [details]
Draft fix

Yep, there are several bugs in the rpmlint code whose combined effect is this
endless recursion plus practically failure to expand any shell values in init
scripts at all.

First, InitScriptCheck.py passes only the _line_ in the init script where the
variable occurs to the shell variable expansion routine.  It needs to pass the
whole script, otherwise there's no hope of getting anything usefully expanded.

Second, constructs such as "FOO=$FOO" in the shell variable expansion routines
do cause endless recursion.

Third, VAR_SUBSYS_IPTABLES=/var/lock/subsys/$IPTABLES is indeed the line that
causes recursion in this case.	The issue is that rpmlint effectively parses
the assignment as IPTABLES=/var/lock/subsys/$IPTABLES - there's a missing start
boundary check in assign_regex in shell_var_value() - so it ends up in the 2nd
case above.

The attached patch should fix all of the above, however I see the shell
variable expansion routines are still pretty feeble and it's easy to construct
cases where they fail to do the expansion correctly.  Dunno if they're worth
having/fixing in the first place, but they're already in and this patch
shouldn't at least make them any worse...

"orig = None" in the signature of shell_var_value() in the patch in comment 4 
is a leftover from some earlier local tests, it will be removed before 
applying this anywhere.

Applied upstream as
http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1286
http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1287
http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1288

OK, I gave your patch a try.

The positive side: "rpmlint -a", "rpmlint iptables", "rpmlint iptables*.rpm"
don't bomb out anymore.

On the negative side: As you say, this "shell expansion" is a semi-functional
hack. I am having doubts if this is the "right approach (tm)" to the problem
rpmlint is trying to solve (consider shell functions, consider "sourcing
functions from inside init scripts).

So, I am I correct in expecting you to update rpmlint in FE5 to render
"rpmlint -a" functional again?

Yep, I'm just going to have a quick look at bug 210110 to see if there's an 
easy fix for it, and then ping other upstream folks to see if they agree the 
accumulated fixes over the past few days are worth a new release (and if not, 
will ship a patched package in the meantime).

See also http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/51 for a request for 
comments regarding removal of the shell var expansion stuff.

Fixed in 0.78-2.fc*