On Aug 29, 2008, at 6:11 AM, Alexey Tourbin wrote:

>
> Now, for some reason, certain rpmquery calls do trigger  
> headerVerifyInfo
> call, and others do not.
>
> $ ./rpm -q --qf '%{NAME}\n' coreutils
> headerVerifyInfo
> headerVerifyInfo
> headerVerifyInfo
> headerVerifyInfo
> headerVerifyInfo
> headerVerifyInfo
> headerVerifyInfo
> headerVerifyInfo
> headerVerifyInfo
> coreutils
> $ ./rpm -q --qf '%{NAME}\n' --whatprovides /bin/cat
> error: rpmdb: damaged header #90 retrieved -- skipping.
> error: rpmdb: damaged header #90 retrieved -- skipping.
> error: rpmdb: damaged header #531 retrieved -- skipping.
> error: rpmdb: damaged header #585 retrieved -- skipping.
> error: rpmdb: damaged header #1101 retrieved -- skipping.
> error: rpmdb: damaged header #1173 retrieved -- skipping.
> file /bin/cat is not owned by any package
> $
>

Ah, the issue perhaps starts to be come clearer.

The headers traversing that code path are likely really ancient "LSB  
format",
headers. All headers I've seen for 7? 8? years have a header SHA1 that
is used instead of the header sanity check. The header sanity check  
is what
fails the RPM_CHAR_TYPE assertion.

Which explains why not reported.

Does that sound consistent with what you are seeing? Checking
RPMTAG_RPMVERSION is one way to check.

(aside) If true, I'm inclined to juts put an assert somewhere in the  
code and end all discussions
about "LSB format" headers. All necessary due diligence for  
converting/upgrading
has been duly performed.

> 9 headerVerifyInfo() calls with '-q' and no single headerVerifyInfo()
> call with '-q --whatprovides'.