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:
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.
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.
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.
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.
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.
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).
From an UI POW, doing mtime on x86_64 is terrible and just means no one trusts rpm -Va anymore