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).
Steps to Reproduce:
1. subscribe to rhel-high availability
2. install luci (with epel enabled).
3. yum will pull epel version.
luci won't start up
luci will startup.
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?
I'm not sure how EPEL is expected to know about the contents of "extra" channels for third party RHEL offerings.
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.
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.
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
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
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.
*** Bug 750474 has been marked as a duplicate of this bug. ***
From that duplicate (bug 750474 comment 6):
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.