On 09/02/2014 12:14 PM, Michael Lampe wrote: > Les Mikesell wrote: >> On Tue, Sep 2, 2014 at 11:24 AM, Michael Lampe >> <mlampe0 at googlemail.com> wrote: >>>> >>> What about some kind of preconfigured protection of base >>> repositories? Epel >>> doesn't live up to their own standards of not replacing system packages: >>> >>> # yum -d3 update | grep epel >>> >>> --> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority) >> (etc.) >> While it's certainly not true in all cases, quite a few of the 'excluded' packages come from owning a common directory rather than actual conflicting files. We found a few of these early on during our testing with 7. Of the ones we found (at the time) none actually conflicted, but were excluded due to shared ownership of a plugin directory like /usr/lib/python2.7/site-packages These should still certainly be corrected. >> Isn't this something that should really be automated with some kind of >> scanning at the repository level (for both package and file name >> conflicts)? >> > > 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. This shouldn't happen, and its stuff like this that we'll be working to address in the future. The EPEL Steering Committee has been reformed[1], and one of the topics has been a cleanup and better documentation of epel policy[2]. So this sort of thing should be minimized moving forward. 1. https://lists.fedoraproject.org/pipermail/epel-devel/2014-August/010060.html 2. https://lists.fedoraproject.org/pipermail/epel-devel/2014-August/009943.html -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77