File conflict in libevent-devel-1.4.13-1: /usr/bin/event_rpcgen.pyc File conflict in libevent-devel-1.4.13-1: /usr/bin/event_rpcgen.pyo File conflict in libevent-devel-1.4.13-1: /usr/include/event-config.h File conflict in libevent-devel-1.4.13-1: /usr/share/doc/libevent-devel-1.4.13/* If you fix the package, please add %{?dist} to Release.
(In reply to comment #0) > File conflict in libevent-devel-1.4.13-1: /usr/bin/event_rpcgen.pyc > File conflict in libevent-devel-1.4.13-1: /usr/bin/event_rpcgen.pyo > File conflict in libevent-devel-1.4.13-1: /usr/include/event-config.h > File conflict in libevent-devel-1.4.13-1: > /usr/share/doc/libevent-devel-1.4.13/* What tool generated this output and what does the output even mean?
So, I'm guessing the problem is that libevent-devel.i686 and .x86_64 (for example) both contain the above files. The fedora packaging guidelines state the following: Multiarch, binaries and compilation scripts In multilib environments there is a preferred architecture, 64 bit over 32 bit in x86_64, 32 bit over 64 bit in ppc64 and sparc64. When a conflict is found between two packages corresponding with different arches, the installed file is the one from the preferred arch. This is very common for executables in /usr/bin, for example. If the file /usr/bin/foo is found in an x86_64 package and in an i386 package, the executable from x86_64 will be installed. These implicit conflicts are accepted in Fedora, though they are considered bad by some contributors. There may be some long-term solution for these issues, but before that there are some tricks that may allow to avoid those conflicts that are presented below. Once again they are optional. (https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#File_conflicts) So, I'm not sure what, if anything, needs to be done abou tthte above file conflicts.
This should be fixed in libevent-1.4.13-1 since that contains the libevent-1.4.13-stable-configure.patch...
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
*** Bug 634919 has been marked as a duplicate of this bug. ***
Seeing this again on 5.8. Possibly caused by RPM fixes: 03:54:31 ERROR : file conflicts: file /usr/bin/event_rpcgen.pyc conflicts between attempted installs of libevent-devel-1.4.13-1.ppc and libevent-devel-1.4.13-1.ppc64 03:54:31 ERROR : error running transaction: file /usr/bin/event_rpcgen.pyc conflicts between attempted installs of libevent-devel-1.4.13-1.ppc and libevent-devel-1.4.13-1.ppc64 03:54:31 ERROR : file conflicts: file /usr/bin/event_rpcgen.pyo conflicts between attempted installs of libevent-devel-1.4.13-1.ppc and libevent-devel-1.4.13-1.ppc64 03:54:31 ERROR : error running transaction: file /usr/bin/event_rpcgen.pyo conflicts between attempted installs of libevent-devel-1.4.13-1.ppc and libevent-devel-1.4.13-1.ppc64 03:54:31 ERROR : file conflicts: file /usr/include/event-config.h conflicts between attempted installs of libevent-devel-1.4.13-1.ppc and libevent-devel-1.4.13-1.ppc64 03:54:31 ERROR : error running transaction: file /usr/include/event-config.h conflicts between attempted installs of libevent-devel-1.4.13-1.ppc and libevent-devel-1.4.13-1.ppc64 The duplicate bug 634919 list several more files which may be in conflict.
Yes this is another "victim" of fixing bug 740291, and again pointing out a serious bug in the package: /usr/include/event-config.h can differ between architectures in several ways. In case of x86_64 vs i386 it differs on _EVENT_SIZEOF_LONG definition, which in turn is used to typedef other types (ev_uint64_t etc), which will either cause miscompilation or compile-errors for the architecture whose include file got overridden (in the previous rpm behavior which ignored the conflict when the packages were installed in the same transaction) The *.pyc and *.pyo conflicts should be technically harmless even if rpm was reverted back to previous behavior, however: a) They shouldn't conflict in the first place. *.pyo and *.pyc are supposed to be arch-independent bytecode, conflict in them suggests a bug in how they are bytecompiled. b) *.pyc and *.pyo files don't belong to /usr/bin. This at least in part rpm's fault, although it could be argued that *.py files dont belong to /usr/bin either.
FYI: the rpm fix has been reverted due to requiring changes to too many packages. So while removing the conflict in packaging would only be the right thing to do, it's not required for RHEL 5.8.
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.
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
This probably won't get fixed in RHEL 5. Closing.