Created attachment 524212 [details] Yum install without conflicts Description of problem: We recently noticed that FhGFS x86_64 and i686 packages not *always* conflict with each other. Version-Release number of selected component (if applicable): FhGFS-11.04 How reproducible: Steps to Reproduce: 1. Add a file /etc/yum.repos.d/fhgfs-el5.repo: [FhGFS] name=FhGFS baseurl=http://www.fhgfs.com/release/fhgfs_2011.04/dists/rhel5 enabled=1 gpgcheck=0 2. yum install fhgfs-storage.x86_64 fhgfs-storage.i686 ==> No conflict, although files DO conflict. 3. yum erase fhgfs-storage.x86_64 fhgfs-storage.i686 rpm -e fhgfs-opentk-lib-2011.04-r5.el5.x86_64 fhgfs-common-2011.04-r5.el5.noarch fhgfs-opentk-lib-2011.04-r5.el5.i686 yum install fhgfs-storage yum install fhgfs-storage.i686 ==> This time files conflict! Actual results: No conflicts in step 1, conflicts in step 3. Expected results: Both time conflicts Additional info: See attachment.
Created attachment 524213 [details] Yum install with conflicts
Yup, rpm 4.4.x permits files to conflict when they occur in the same transaction, but not when the same packages are installed one by one in separate transactions. It's been long long since fixed in later rpm releases, and I thought it went to RHEL 5 too but apparently not... The behavior is confusing, stupid and just wrong. Ack from my POV to fix it, as long as it doesn't cause too many problems in the RHEL-5 package set (these would be packaging bugs but in the unlikely case that it happened to affect tens/hundreds of packages the fix would just have to be reverted in practise)
This https://bugzilla.redhat.com/show_bug.cgi?id=756304 was probably also casued by fix of this bug.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Unfortunately so many existing packages rely on this broken behavior that the cure ends up being worse than the disease for RHEL-5. NAK. Oh well, at least we tried.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.