Description of problem:
"rpm -qp not_a_file" returns incorrect return code
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rm -f not_a_file
2. rpm -qp not_a_file
3. echo $?
I tried on RHEL-4 and it is OK (returns 1). On Fedora Development rpm returns 0
Yup.. rpmgiNext() stops the iteration on errors and doesn't differentiate the
error case vs normal end of iteration, making accurate error reporting
impossible AFAICT unless api or at least rpmgiNext() return semantics are changed.
The semantics will be changed this weekend ;-)
changeset 6020: 7db24f0e47a5
just noticed this (on x86_64 system where are no *.s390 packages):
$ rpm -q libbonobo.s390
$ echo $?
But libbonobo i386 & x86_64 packages are installed:
$ rpm -q libbonobo
Probably this is relevant to this bug?
Actually, your example in #4 is a different flaw, fixed in other ways quite some
time ago in rpm-4.4.9, and recently in 18.104.22.168 as well.
The RPM rebase in 5.3 / Fedora 9 includes a fix for this issue
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.