On 07/09/2014 04:52 PM, Karanbir Singh wrote: > On 07/09/2014 01:19 PM, Manuel Wolfshant wrote: >> On 07/09/2014 03:14 PM, Karanbir Singh wrote: >>> On 07/09/2014 12:24 PM, Johnny Hughes wrote: >>>> On 07/09/2014 02:37 AM, Karanbir Singh wrote: >>>>> hi, >>>>> >>>>> We are going to need to find a way to address content in CentOS ( or >>>>> well, content in EPEL ) where there are packages in centos that didnt >>>>> come from rhel but are going to overlap with whats in EPEL. >>>>> >>>>> Technically, this is a centos.org issue since EPEL's mandate requires >>>>> them to not overlap with RHEL[1]. But with stuff going into >>>>> CentOS-Extras/ and more content coming onboard from SIG's - and even >>>>> from Core SIG - how are we going to address the overlap / flapping >>>>> potential with EPEL ? >>>>> >>>>> I am going to be pulling in cloud-init with a couple of deps, need to >>>>> have these in the centos.org repos to do cloud instance builds. >>>>> >>>>> - KB >>>>> >>>>> [1]: I am not sure if EPEL cant overlap with base RHEL or with variants >>>>> and layered products ? >>>>> >>>> The only real way to handle it is with excludes or priorities in the yum >>>> config files .. that, or some other thing like epochs or higher versions >>>> in the centos.org content to make it newer (assuming that is the goal). >>> I am hoping we can find a way to communicate this and sync with the epel >>> folks in a manner that it does not cause too much issues. priorities >>> will help i guess, but it will cause issues when people want to consume >>> one and not the other ( either way ), specially when its down to libs >>> >>> >> Can;t we go with a new/separate repo , default disabled, with different >> (higher) priority ? > if we disable extras, we've cut off epel completely. Also sig's and > other efforts wont want to ship orhpahed code, so they will want their > own content to always be visible. I explicitely mentioned a *separate* repo. The idea of keeping it default disabled was in sync with shipping the [repo] config for it in centos-release, but if we ship in extras a newrepo-release.rpm for it, we can leave it enabled as it should get installed only by those needing it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140709/fdd2b35d/attachment-0007.html>