Bug 1256545 - EPEL 7 updates packages that are in the RHEL 7 distribution: libgpod, libsrtp, python-qrcode-core
Summary: EPEL 7 updates packages that are in the RHEL 7 distribution: libgpod, libsrtp...
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: libgpod
Version: epel7
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Moez Roy
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-08-24 21:51 UTC by Giacomo G. Brussino
Modified: 2015-08-26 16:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-08-24 22:59:13 UTC

Attachments (Terms of Use)

Description Giacomo G. Brussino 2015-08-24 21:51:43 UTC
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

Comment 1 Moez Roy 2015-08-24 22:59:13 UTC
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 ***

Comment 2 Giacomo G. Brussino 2015-08-25 16:51:55 UTC
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.

Comment 3 Orion Poplawski 2015-08-25 17:07:44 UTC
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:


Comment 4 Giacomo G. Brussino 2015-08-25 19:10:51 UTC
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.

Comment 5 Moez Roy 2015-08-25 22:42:17 UTC
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.

Comment 6 Giacomo G. Brussino 2015-08-26 16:16:52 UTC
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

Note You need to log in before you can comment on or make changes to this bug.