<div dir="ltr">On Fri, Jan 17, 2014 at 12:06 PM, Jim Perrin <span dir="ltr"><<a href="mailto:jperrin@centos.org" target="_blank">jperrin@centos.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/17/2014 10:06 AM, Ljubomir Ljubojevic wrote:<br>
> So how do you intend to solve this without priorities? Especially if<br>
> there is a need for some packages to be compiled with different flags?<br>
<br>
</div>Ideally by eliminating package duplication for the SIG/repos who work<br>
with us, but that's an ivory tower goal that's likely unattainable.<br></blockquote><div><br></div><div>We certainly want to reduce it and box it in. It's clear that we do want to allow overlap, but we need to try to build some sanity into it and avoid it when it is not truly necessary<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It will likely be a combination of working with SIGs to coordinate and<br>
cooperate, changing to SCL builds where possible and appropriate, and<br>
documentation to better educate the users.<br>
<br>
SCL builds provide a nice name-spaced way to have multiple versions of<br>
the same packages installed. For example, python27, python33, multiple<br>
php and httpd versions, etc. All of which are mostly impractical with<br>
the older rpm packaging style (see php and httpd for example). This is<br>
by no means a silver bullet, but it does solve a fair chunk of the issue.<br>
</blockquote><div> <br></div><div>Agreed. SCLs are a natural fit here<br></div><div><br></div><div>Without SCLs, the SIG will actually be overriding the base package. There are a host of potential problems here, repo priority is the least of it.<br>

For major significant changes this could spiral into a dependency nightmare, or simply break things in the base distro. For minor changes (small change, bump release), the such issues would be less likely. For overriding with higher versions, the repo priority plugin would be unnecessary. For release bumps, the SIG would have to track the base closely to stay ahead (granted they should probably do that anyway).<br>

<br></div><div>At any rate my point is that there are many different reasons to do this and many different ways it which it might be done. Some approaches will be sane, and others very, very unwise. I suspect that we'll wind up with a fairly long policy document delineating these different cases, stating what is allowed, and listing best practices.<br>

</div></div></div></div>