Bug 171279

Summary: rpm --verify gives wrong results on multilib
Product: [Fedora] Fedora Reporter: Avi Kivity <avi>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED WONTFIX QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: k.georgiou, nicolas.mailhot
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-06 12:46:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235757    

Description Avi Kivity 2005-10-20 11:10:27 UTC
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}.
%{arch}\n' 
openssl-0.9.7f-7.10.x86_64 
openssl-0.9.7f-7.10.i686 
 
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):
rpm-4.4.1-22

How reproducible:
Always

Steps to Reproduce:
1. rpm --verify openssl 
   

Actual Results:  verify errors  

Expected Results:  no errors 

Additional info:

Comment 1 Paul Nasrat 2005-10-20 14:32:50 UTC
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 15:13:47 UTC
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-13 02:40:12 UTC
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-13 03:02:21 UTC
it works for install and update. it should work for verify and query. 
 
  [root@cleopatra ~]# rpm -qf /sbin/pam_tally --qf '%{name}.%{arch}\n' 
  pam.i386 
  pam.x86_64 
  [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 12:46:54 UTC
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 13:47:54 UTC
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 13:34:03 UTC
From an UI POW, doing mtime on x86_64 is terrible and just means no one trusts
rpm -Va anymore