Bug 741324 - python-repoze-who-friendlyform from epel overwrites RHEL version
Summary: python-repoze-who-friendlyform from epel overwrites RHEL version
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: python-repoze-who-friendlyform
Version: el6
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
: 750474 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-26 15:19 UTC by Moritz Baumann
Modified: 2018-11-26 18:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-17 17:16:58 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 750474 0 unspecified CLOSED luci didn't start 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 750931 0 unspecified CLOSED Inconsistency between EPEL's RPM and Python's packaging system metadata -- requires 2021-02-22 00:41:40 UTC

Internal Links: 750474 750931

Description Moritz Baumann 2011-09-26 15:19:21 UTC
Description of problem:

epel version replaces package from rhel-ha and breaks luci.

more general epel version replaces rhel version!!

Version-Release number of selected component (if applicable):

python-repoze-who-friendlyform-1.0-0.3.b3.el6.noarch.rpm (RHEL-HA channel)
python-repoze-who-friendlyform-1.0.8-2.el6.noarch.rpm (from epel).

How reproducible:


Steps to Reproduce:
1. subscribe to rhel-high availability
2. install luci (with epel enabled).
3. yum will pull epel version.

Actual results:

luci won't start up

Expected results:

luci will startup.

Additional info:


but only 

WebOB>=0.9.6 available in RHEL.

Setting this back to 

0.9.6 manually will allow luci to start up again.

But from: http://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterprise_Linux_.28or_EPEL.29.3F

EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. 

although HA is not a base channel but must be purchased my understending was that I can always have epel enabled as an additional repo.

Could you please either clarify on the EPEL package that this only holds for the base channel (rather than distribution) and NOT for HA, resilient storage, etc. or fix this that the above statement holds true?

Moritz Baumann

Comment 1 Tom "spot" Callaway 2011-09-26 16:10:53 UTC
I'm not sure how EPEL is expected to know about the contents of "extra" channels for third party RHEL offerings.

Comment 2 Moritz Baumann 2011-09-27 08:43:57 UTC
So should I file a bug against luci or the python-repoze-who-friendlyform-1.0-0.3.b3.el6.noarch.rpm from RHEL?

I just think its a bad thing that an epel package breaks the functionality of a RHEL package (be it from core or extra channel) and my question is where/who to correctly address this issue.


Comment 3 Tom "spot" Callaway 2011-09-27 13:41:11 UTC
I have no idea. While I sympathize with your concern, I'm not sure I can replace the EPEL package with the older RHEL version at this point.

Comment 4 Moritz Baumann 2011-09-27 14:34:44 UTC
well maybe the other way around works?

Maybe it is possible to push this package to rhel-ha and fix the dependencies (although I have not checked what other packages rely on this package (or the rhel-ha version)?

Our first work around (using the epel package) was just to change the line

< WebOb>=0.9.7
> WebOb>=0.9.6



I'm not sure if this actually breaks something or not.

Another option would be provide a python-webob-0.9.7....noarch and require this in your package since you require this implicitely 
in /usr/lib/python2.6/site-packages/repoze.who_friendlyform-1.0.8-py2.6.egg-info/requires.txt


Comment 5 Tom "spot" Callaway 2011-10-17 17:16:58 UTC
I think the best solution here is to exclude the conflicting package via yum. In your /etc/yum.repos.d/epel.repo (or whatever it is named), under [epel-6] (or again, whatever it is named) add:


I do not believe it is possible to account for non-core RHEL offerings in EPEL, nor do I wish to change the WebOb requires to 0.9.6 (I'm sure upstream set it to 0.9.7 for a reason, but at this point, I can't easily discover why), and I am uninterested in maintaining a python-webob098 package and patching python-repoze-who-friendlyform to use it.

Comment 6 Jan Pokorný [poki] 2011-11-02 21:07:03 UTC
*** Bug 750474 has been marked as a duplicate of this bug. ***

Comment 7 Jan Pokorný [poki] 2011-11-02 21:15:14 UTC
From that duplicate (bug 750474 comment 6):

Side note:
But to be honest, what is the real problem in this particular case
(at least from what I have seen) is broken consistency between EPEL's RPM
and contained Python package metadata, more specifically package
dependencies.  I have filled bug 750931 to address this.
Still and once again, luci + EPEL packages combination is discouraged.

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