On Apr 12, 2016, at 2:14 PM, Rajul Bhavsar wrote:
> 
> Hmm why rpm-5.1.9, which was released quite some time ago?
> >>>> Yes, its older version. But that is what current version we had. Will like to move to 5.4.14 in near future and that rpm version performs all required queries perfectly fine.
>> $ rpm -qai
>> rpm: -qai: unknown option
>> $
>> 
> 
> Try a simpler query first: does rpm -qa "work"?
>  
> >>>> Yes, -qa works, but --xml or --yaml do not work along with -qpi. Also, use of --force give same error in rpm -iv command.
>  

OK. All of -i/--info, --xml and --yaml are popt aliases.

Make sure (with strace -e open) that rpm can read /usr/lib/rpm/rpmpopt.

You can also (for --xml and --yaml at least) verify with --queryformat.

All that --yaml does is add this --queryformat option:

	rpm -q --qf '[%{*:yaml}\n]' bash

> The -i option is contextually dependent with multiple meanings in rpm
> and the processing is painfully complex. Identifying what does and does not
> work will be helpful in finding a fix.
> 
>> When we try to query custom metadata (implemented using arbitrary tags) then also it is failing (giving output as (none)). We have proper macro file in /usr/lib/rpm-5.1.9/macros and rpm is referring to it.
>> 
> 
> (from memory of a recent patch from Poky/Yocto)
> 
> The arbitrary tag values are likely in native endian.
> Did you build and query both on the same machine, or are you
> trying to query a package built on x86_64 on a ppc* machine?
>  
> >>>> rpm files are generated on x86_64 machines but querying it on ppc machines (arch within rpm is ppc). Inbuilt metadata can be queried using --qf but not custom metadata. I guessed that endianness should not have impact rpm metadata content. But, even if it has, then it should give garbled values and not "(none)" as its result. However, querying custom metadata works fine in 5.4.14.
>  

Yes arbitrary tags in metadata should be platform independent as a goal. But not in rpm-5.1.9 == a bug.

The tag itself, not its content, is what is not platform independent. Hence not "garbled".

With arbitrary tags, there are never any missing tags, any tag name will do.
RPM queries have always returned '(none)' in-band (i.e. in the actual output string)
for optional tags. That behavior has been extended to arbitrary tags.

hth

73 de Jeff