Bug 171279 - rpm --verify gives wrong results on multilib
Summary: rpm --verify gives wrong results on multilib
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
(Show other bugs)
Version: 4
Hardware: x86_64 Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 235757
TreeView+ depends on / blocked
 
Reported: 2005-10-20 11:10 UTC by Avi Kivity
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

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: ---


Attachments (Terms of Use)

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


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