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: http://lists.fedoraproject.org/pipermail/cloud/2012-November/001975.html 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": https://www.redhat.com/archives/epel-devel-list/2012-November/msg00048.html So, I think we'll probably end up just removing OpenStack from EPEL and using separate repositories like these ones: http://repos.fedorapeople.org/repos/openstack/ 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: http://repos.fedorapeople.org/repos/openstack/openstack-essex/epel-openstack-essex.repo Phew. Makes sense? Thanks, Mark. _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
