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@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