<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 2 September 2014 11:14, Michael Lampe <span dir="ltr"><<a href="mailto:mlampe0@googlemail.com" target="_blank">mlampe0@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Les Mikesell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Sep 2, 2014 at 11:24 AM, Michael Lampe <<a href="mailto:mlampe0@googlemail.com" target="_blank">mlampe0@googlemail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
What about some kind of preconfigured protection of base repositories? Epel<br>
doesn't live up to their own standards of not replacing system packages:<br>
<br>
# yum -d3 update | grep epel<br>
<br>
  --> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority)<br>
</blockquote>
(etc.)<br>
<br>
Isn't this something that should really be automated with some kind of<br>
scanning at the repository level (for both package and file name<br>
conflicts)?<br>
<br>
</blockquote>
<br></div>
What if some package from epel gets included by RH with an update? This happened several times in the past and epel always kept their package available, even if had a higher version number than the now official RH package.<span class="HOEnZb"><font color="#888888"><br>

<br></font></span></blockquote><div><br></div><div>That should not happen (but it does because we aren't connected to what is in releases so end up with surprises every dot release) . Our process is meant to be the following:</div>
<div><br></div><div>1) Put package in EPEL.</div><div>2) At dot release make sure packages are not in core.</div><div>3) If in core, remove or move our package to a NEVR that won't be replaced by in-stream package. </div>
<div><br></div><div>One problem is that there are many many sub-channels for RHEL of which we only counted a couple as 'core' because we had access to them on a general Enterprise account. We then end up with packages which are different from shipped packages because rhel-some-channel-6.5 had a package which conflicts with EPEL. At the moment, we are looking at having a 'if it is in Base CentOS we aren't going to conflict.' policy. This will take some doing still but should allow for us to clean up our act.<br>
</div><div><br></div><div>The secondary problem is that if you had package-1.2.4-8 and RHEL releases its next dot release with package-1.2.3-6.. you are stuck with the version EPEL had in it and nothing can be done about it. We can remove it from the repo but your system will have a version which won't see any updates. That is the nature of secondary channels.. and I don't see anything but a yum plugin which says 'base channel has newer but older package in it please rebase'</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
-Michael</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org" target="_blank">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/<u></u>mailman/listinfo/centos-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Stephen J Smoogen.<br><br></div>
</div></div>