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

Wed Jul 9 16:41:52 UTC 2014
Sven Kieske <svenkieske at gmail.com>

Hash: SHA1

On 09.07.2014 09:37, 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 honestly think each sig should sort their issues out themselves.
reasoning with example:
As a matter of fact you can easily create sig a and sig b
where sig a wants package x from base repo and sig b wants package
x from epel -> you can't make both happy -> they need to make
themselves happy by specifying their own repo structure or package
pinning and which package comes from which repo.
projects like ovirt already do this on EL6 with some third party
repos for gluster, epel etc.

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

where do you pull cloud-init in? in base or in a non-core sig?
cloud-init was in epel for el6 if I remember correctly.
I don't see it in "base" for the core sig, it could still reside in epel.
the cloud sig might choose to define their own extra cloud repo on top
and prefer maybe a newer cloud-init from their cloud-repo over the
version in epel. (I haven't checked versions, this is just a made up

As for the "core" sig which might conflict with epel:

should there really be any conflicts?
Is there a list of conflicting packages somewhere?

I can imagine this for i686 builds as they are not provided
by upstream, but for the plain core?
Version: GnuPG v2.0.22 (MingW32)