From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051202 CentOS/1.5-1.c4.centos4 Firefox/1.5 Description of problem: When doing arch specific querries on x86_64 EL4, it turns up that gpg keys have no Arch tag. Should gpg keys not be marked as noarch ? Version-Release number of selected component (if applicable): rpm-4.3.3-11_nonptl How reproducible: Always Steps to Reproduce: 1.rpm --qf "%{name}.%{arch}\n" -q gpg-pubkey-* Actual Results: gpg-pubkey.(none) gpg-pubkey.(none) gpg-pubkey.(none) gpg-pubkey.(none) Expected Results: gpg-pubkey.noarch gpg-pubkey.noarch gpg-pubkey.noarch gpg-pubkey.noarch Additional info: This issue is persistant on i386 / x86_64 and ppc64 platforms.
GPG pubkeys don't come from packages, a header is used merely as a container, so its arguable whether they should be ,marked "norach" or not. There certainly is no arch associated with GPG pubkeys. The real problem is more subtle, returning '(none)' in-band rather than out-of-band, i.e. returning a condition, not a value, as part of a value stream. So the better fix is to filter out '.(none)', perhaps substituting ".pubkey" explicitly, instead. Here's one example that I use daily %_query_all_fmt %%{name}-%%{version}-%%{release}.%%|SOURCERPM?{%%{arch}.rpm}:{%%|ARCH? {src.rpm}:{pubkey}|}| Note that non-existence of an arch tag is being used to substitute "pubkey" for an RPMTAG_ARCH substitution. WONTFIX ("noarch" is not the right fix) imho
Upstream development is heading towards getting the gpg-pubkeys out of the rpmdb which will avoid this issue for good... but not going to change the behavior for RHEL 4.