Bug 171279 - rpm --verify gives wrong results on multilib
rpm --verify gives wrong results on multilib
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
Depends On:
Blocks: 235757
  Show dependency treegraph
Reported: 2005-10-20 07:10 EDT by Avi Kivity
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-06 07:46:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Avi Kivity 2005-10-20 07:10:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.2 (like Gecko)

Description of problem:
rpm --install or --update handle duplicate files in multilib packages just 
fine. rpm --verify, however, doesn't: 
[root@cleopatra ~]# rpm --verify openssl | head 
.......T.   /etc/pki/tls/certs/Makefile 
.......T. c /etc/pki/tls/certs/ca-bundle.crt 
.......T.   /etc/pki/tls/certs/make-dummy-cert 
.......T.   /etc/pki/tls/misc/CA 
.......T.   /etc/pki/tls/misc/c_hash 
.......T.   /etc/pki/tls/misc/c_info 
.......T.   /etc/pki/tls/misc/c_issuer 
.......T.   /etc/pki/tls/misc/c_name 
.......T. c /etc/pki/tls/openssl.cnf 
.......T. d /usr/share/man/man1/asn1parse.1ssl.gz 
[root@cleopatra ~]# rpm -q openssl --qf '%{name}-%{version}-%{release}.
these files are present in both packages, but only the x86-64 ones are 
installed. they have different mtimes so rpm verification fails 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. rpm --verify openssl 

Actual Results:  verify errors  

Expected Results:  no errors 

Additional info:
Comment 1 Paul Nasrat 2005-10-20 10:32:50 EDT
rpm -V openssl.x86_64 should be fine, rpm -V openssl.i386 will complain  due to
the way that multilib works to prefer ELF64 in multiple install case.
Comment 2 Avi Kivity 2005-10-20 11:13:47 EDT
yes. I believe the correct behavior for rpm --verify is 
  if (!((arch is inferior) && (file exists in main arch package))) 
      if (file fails tests) 
          report bad file 
rpm should not report problems where everything is operating as expected. 
Comment 3 Jeff Johnson 2005-11-12 21:40:12 EST
There is no "arch is inferior" or "exists in main arch", so the (otherwise
correct algorithm) cannot be implemented. i386 and x86_64 are equal,
the policy choice and decision of "inferior" and "main" cannot currently
be specified to rpm.
Comment 4 Avi Kivity 2005-11-12 22:02:21 EST
it works for install and update. it should work for verify and query. 
  [root@cleopatra ~]# rpm -qf /sbin/pam_tally --qf '%{name}.%{arch}\n' 
  [root@cleopatra ~]# file /sbin/pam_tally 
  /sbin/pam_tally: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), 
for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped 
rpm knows to install the 64-bit version of /sbin/pam_tally. it knows how to 
update it. it should know which package it came from. 
Comment 5 Jeff Johnson 2006-01-06 07:46:54 EST
Invoke rpm --verify with --nomtime if you don't want to see the output spew
for files that indeed have a modified mtime because they have been replaced.
Comment 6 Avi Kivity 2006-01-06 08:47:54 EST
You also have to specify --nosize and --nomd5. Better yet, avoid running rpm 
--verify altogether, since it doesn't tell you anything useful: whether the 
package's files differ from the original installation. 
Luckily we have CLOSED, WONTFIX and CLOSED, NOTABUG so we don't have to worry 
about these problems (this is not the first time I see an obvious bug ignored 
in Fedora). 
Comment 7 Nicolas Mailhot 2006-07-13 09:34:03 EDT
From an UI POW, doing mtime on x86_64 is terrible and just means no one trusts
rpm -Va anymore

Note You need to log in before you can comment on or make changes to this bug.