-----BEGIN PGP SIGNED MESSAGE----- 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 example).
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?