differences between epel and official RHEL-OpenStack

Mark McLoughlin markmc at redhat.com
Thu Nov 29 12:16:27 UTC 2012

Hey Florian,

Good questions, thanks!

Cross-posting to epel-devel because it's related to a recent discussion
about the Essex->Folsom update in EPEL. Apologies if the cross-posting
offends anyone :)

Florian's original mail was:


On Thu, 2012-11-29 at 11:51 +0100, Florian La Roche wrote:
> Hello,
> Seems like Red Hat is building the official Red Hat OpenStack product
> rpms sometimes with the exact same name as the ones within EPEL.
> The below difference shows that in this case EPEL seems to be a bit ahead,
> but it also looks like this fix is then also not yet merged into the Folsdom
> release that should show up for RHEL6.4.
> There are other rpms where also changes are done to dependencies without
> any changelog entry. Often with changing the version name, but not always.
> All this is usually a bad idea.

To clarify one thing, OpenStack isn't in RHEL - Red Hat OpenStack (RHOS)
is layered product separate from RHEL.

Over time, RHOS will evolve in a similar way to RHEL - it will be
supported for longer time periods, there'll be tonnes of backports,
we'll probably skip some releases, etc.

However, we want to make the latest upstream version of OpenStack easily
available for RHEL/CentOS/SL/etc. users and for this to not be subjected
to the kind of constraints RHOS has. Basically, we want the version of
OpenStack that's in Fedora to be available for RHEL/CentOS/SL/etc too.

At the moment, we're using EPEL for this and the RHOS version is very
similar to what's in EPEL. We're currently figuring out how this should
evolve, so your question is pretty topical :)

We learned a lesson with the Folsom update recently. EPEL probably isn't
the best place for "the Fedora version of OpenStack packaged for RHEL":


So, I think we'll probably end up just removing OpenStack from EPEL and
using separate repositories like these ones:


As for your python-daemon example - it's one of the packages that exists
both in EPEL and RHOS. The two repositories are basically conflicting
over the same n-v-r space, which is bad. We avoid that problem with RHEL
vs EPEL by saying no packages which exist in RHEL should also exist in
EPEL. It's pretty obvious that the same rule doesn't make sense for RHOS
vs EPEL - just because we pull something into RHOS, doesn't mean it
should be removed from EPEL.

The solution we've been assuming so far is yum-priorities. If you use
RHOS and EPEL, your RHOS repo should be configured with a lower priority
number than the default of 99 which is assigned to the EPEL repo.

We probably should have a rhos-release RPM which contains the RHOS .repo
file with a priority and have this RPM depend on the yum-priorities
plugin RPM.

We're also using this scheme to give e.g. the Essex repo higher priority
over EPEL, since EPEL contains the Folsom packages:


Phew. Makes sense?


More information about the cloud mailing list