Bug 1256545 - EPEL 7 updates packages that are in the RHEL 7 distribution: libgpod, libsrtp, python-qrcode-core
EPEL 7 updates packages that are in the RHEL 7 distribution: libgpod, libsrtp...
Status: MODIFIED
Product: Fedora EPEL
Classification: Fedora
Component: libgpod (Show other bugs)
epel7
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Moez Roy
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-24 17:51 EDT by Giacomo G. Brussino
Modified: 2015-08-26 12:16 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-24 18:59:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Giacomo G. Brussino 2015-08-24 17:51:43 EDT
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 18:59:13 EDT
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 12:51:55 EDT
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 13:07:44 EDT
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
Comment 4 Giacomo G. Brussino 2015-08-25 15:10:51 EDT
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 18:42:17 EDT
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 12:16:52 EDT
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.