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

[Nico Kadel-Garcia]

On Wed, Jul 9, 2014 at 7:24 AM, Johnny Hughes <johnny at centos.org> 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).
>
> This will cause issues though, that will will need to work to fix and
> provide instructions for in an FAQ, etc ... when they arise.

One approach, used by Red Hat themselves, is to put a minor version
number or insert the vendor name in the package name itself, such as
'samba4' or the various java packages and openssl packages. And meta
packaging has been used effectively for years for Java and SMTP
servers and web servers.

It's not always applicable, especially of both repositories
independently provide the same package. It also causes issues when one
repository uses differently organized packaging for the *same*
software, such as has been occurring with nagios-plugins on EPEL and
Repoforge for years, and it's an ongoing reason to apply 3rd party
repositories only as needed to a stable server, and with specific
targeted packages.

Comments that are not just in a FAQ, but also in the
/etc/yum.repos.d/*.repo files themselves for known conflicts might be
particularly useful. If EPEL is going to continue using CentOS by
default for 'mock', software building, it certainly makes sense to
collaborate in keeping the tools compatible, and they seem nice folks.