Description of problem: I do not understand why EPEL 7 would update packages that are in the RHEL 7 distribution like libgpod, libsrtp, python-qrcode-core Version-Release number of selected component (if applicable): RHEL 7 packages: libgpod.x86_64 0.8.2-11.el7 @anaconda/7.1 libsrtp.x86_64 1.4.4-10.20101004cvs.el7 @anaconda/7.1 python-qrcode-core.noarch 5.0.1-1.el7 @anaconda/7.1 EPEL 7 packages: libgpod.x86_64 0.8.3-6.el7 @epel libsrtp.x86_64 1.4.4-13.20101004cvs.el7 @epel python-qrcode-core.noarch 5.0.1-2.el7 @epel How reproducible: if rhythmbox, kdenetwork-* and ipa-python are installed, then "yum update" after activating the EPEL 7 repo tried to update the packages listed above. Steps to Reproduce: 1. install rhythmbox, kdenetwork-* and ipa-python 2. activate EPEL 7 repo 3. run "yum update" Actual results: libgpod, libsrtp, python-qrcode-core get updated with packages from EPEL Expected results: libgpod, libsrtp, python-qrcode-core should not be updated Additional info: rhythmbox (x86_64 2.99.1-3.el7 @anaconda/7.1 requires libgpod kdenetwork-* require libsrtp, but those packages are also from @anaconda/7.1 ipa-python (x86_64 4.1.0-18.el7_1.4 @rhel-7-workstation-rpms) requires python-qrcode-core
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1234052#c1 (In reply to Moez Roy from comment #1) > (In reply to John T. Rose from comment #0) > > This appears to be a weird case for the no replacement policy in EPEL since > > libgpod is available for RHEL7 Workstation and Client but not for Server. So > > I guess I could see an argument either way about including it in EPEL but > > these conflicts are frustrating when the end user of EPEL expects there to > > be no conflicts. > > The koji build root uses the Server. If I retire this package it will then > break the dependencies. > > Also you need to consider that there is some mono bindings which are not in > either the Workstation/Client (which is provided by this package). *** This bug has been marked as a duplicate of bug 1234052 ***
So there might be a reason for libgpod to update a base package, but then the new version should also go in the base. I have seen no explanation about libsrtp and python-qrcode-core. EPEL is also updating these base packages.
Currently EPEL only promises to not override packages in RHEL7 Server. It makes no claims about RHEL7 Workstation. There may need to be more discussion but that is the situation at the moment: https://lists.fedoraproject.org/pipermail/epel-devel/2015-August/011489.html
Could EPEL use the base packages from the workstation instead of building new versions of libgpod, libsrtp, python-qrcode-core for the server? That would prevent issue on the workstation.
With EPEL repo turned on do: yum install banshee Turn Off the EPEL repo and do: yum distro-sync You will notice that there is a problem because some packages are not provided, see http://koji.fedoraproject.org/koji/buildinfo?buildID=589869 for example: libgpod-sharp The best solution here would be for Redhat to provide banshee and its dependencies in their server repo (then I can retire the packages from EPEL). But for that you will need to probably file a ticket with your Redhat support/sales rep.
RHEL 7 workstation has libgpod and libgpod-devel 0.8.2-11.el7. EPEL provides libgpod, libgpod-devel, libgpod-doc, libgpod-sharp and libgpod-sharp-devel 0.8.3-6.el7. If EPEL was providing the same packages @ version 0.8.2-11.el7 there would be no conflict with the base distro. Same for libsrtp: libsrtp.i686 1.4.4-10.20101004cvs.el7 rhel-7-workstation-rpms libsrtp.x86_64 1.4.4-13.20101004cvs.el7 epel libsrtp-devel.i686 1.4.4-10.20101004cvs.el7 rhel-7-workstation-optional-rpms libsrtp-devel.x86_64 1.4.4-13.20101004cvs.el7 epel and python-qrcode-core: python-qrcode-core.noarch 5.0.1-1.el7 @/python-qrcode-core-5.0.1-1.el7.noarch Available Packages python-qrcode-core.noarch 5.0.1-2.el7 epel
libsrtp libgpod python-qrcode-core are no longer in epel7.