On Thu, Feb 27, 2014 at 10:01 AM, Karanbir Singh <mail-lists at karan.org> wrote: > On 02/26/2014 04:47 PM, Les Mikesell wrote: >> It is the inclusion policy that is the problem with EPEL - the >> technical side is fine. And I see less chance than ever of changing >> that. > > not sure how you say the technical side is fine, for me - its the > biggest sticking point about relying on external code. In my experience of using it - for about as long is CentOS and EPEL have been around, I can't say that I've ever seen a problem that I could blame on a badly-managed EPEL rpm or repo, other than the fact that they don't consider centos-extras to be 'upstream' - or for that matter any other 3rd party repo, so there is a potential for duplication. >If content in > centos.org relies on external repo's - we need to have established a > mechanism that allows sync of content before its released. and if we > dont rely on that external code, why have it accessible ? I don't understand this part. "You" may not need EPEL content for the base, but many/most CentOS users will and most SIGs with additional content will need either EPEL or duplicated packages from there. A full mirror would be fine, maybe even better if you can do better vetting before things go from epel-testing to your general release, but it seems silly to duplicate it unless you seriously think you can do a better job with that volume and not slow down new additions. I think cooperation would make more sense. And I'd still like to know if it is possible to automate testing of multiple remote repos to detect potential conflicts and package/file duplication. -- Les Mikesell lesmikesell at gmail.com >