Hide Forgot
Description of problem: This is on RHEL6, although the issue is demonstrated with 3rd party packages. We have a custom noarch rpm (CoRA) that provides /usr/sbin/backup - a shell script. If I install openafs from the ScientificLinux repos, which provides /usr/sbin/backup an elf binary, rpm doesn't complain: # rpm -Uvh openafs-1.6.0-93.pre4.sl6.x86_64.rpm Preparing... ########################################### [100%] 1:openafs ########################################### [100%] And it still thinks the CoRA package is okay. # rpm -V CoRA # Version-Release number of selected component (if applicable): rpm-4.8.0-12.el6.x86_64 How reproducible: Every time I do get conflict messages on our Fedora machines and openafs from rpmfusion.
Your Fedora machines are i386 (well, any 32bit ix86), right? This is easily reproducable on Fedora x86_64 too, it's an ages old flaw in how conflicts are calculated on multilib systems: file conflicts are resolved to prefer 64bit ELF files over 32bit (by default), but all (AFAICT) released versions of rpm prefer 64bit ELF over non-ELF files (such as scripts) too, which is wrong. Fixed upstream now and also ACK for RHEL.
Yeah, I tested with i386 Fedora.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1737.html