Because I get tired of looking at same old "rpm -qa" sopew, I usually
run a tricked up queryformat that looks much like a package file name.

One of the consequences of that is I end up looking at different
rpm -qa spewage than y'all.

So I just noticed

libXinerama-devel-1.0.2-1.fc7.i386
gpg-pubkey-f322929d-3cd5f0d5.(none)
imlib-1.9.15-2.fc7.i386

specifically the  "(none)" because, indeed, public keys
do not (and should not) have a RPMTAG_ARCH.

The fundamental rpm problem is a design flaw, returning "(none)"
as a missing value indicator in-band, rather than out-of-band,
(and on stdout, not stderr, another in-band problem).

Well in-band notification was just peachy in 1997 but is deficient
in many many ways, not the least of which is that each and
every script written against rpm -q spewage needs to filter
(none).

There are further rather complicated i18n issues using "(none)" as
a missing value indicator, but let's not go there.

I'm very likely to start addressing the fundamental design flaw
Real Soon Now, with a --gud-old-behavior opt-in option for
those who cannot fix their scripts.

Meanwhile, the quick-n-dirty hack-a-round is to invent
Yet Another Arch: "pubkey".

Hey, if powerpc can have 8 arch identifiers, why can't rpm have both
"noarch" and "pubkey"?

Any objections to another sick hack in rpm-5.0?

73 de Jeff