<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 07/09/2014 04:52 PM, Karanbir Singh
wrote:<br>
</div>
<blockquote cite="mid:53BD4935.6020409@karan.org" type="cite">
<pre wrap="">On 07/09/2014 01:19 PM, Manuel Wolfshant wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 07/09/2014 03:14 PM, Karanbir Singh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 07/09/2014 12:24 PM, Johnny Hughes wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 07/09/2014 02:37 AM, Karanbir Singh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 ?
</pre>
</blockquote>
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">Can;t we go with a new/separate repo , default disabled, with different
(higher) priority ?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
I explicitely mentioned a <b>separate</b> 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.
</body>
</html>