[CentOS-devel] Overlap between EPEL and CentOS ( non upstream pkgs )

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-0003.html>