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"
libgpod, libsrtp, python-qrcode-core get updated with packages from EPEL
libgpod, libsrtp, python-qrcode-core should not be updated
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:
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:
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
python-qrcode-core.noarch 5.0.1-1.el7 @/python-qrcode-core-5.0.1-1.el7.noarch
python-qrcode-core.noarch 5.0.1-2.el7 epel