On 23 May 2012 23:18, Stephen John Smoogen <[email protected]> wrote: > The issue is that if EPEL pulls out core packages every time Red Hat > decides to offer a sub-channel of supported, then there is no need for > EPEL since it will get gutted regularly.
>From what I recall, we had basically decided to ship rebuilds of the Red Hat RPMs where EPEL would end up gutted due to RPMs getting pulled out of the middle of dependency trees where Red Hat were shipping in a side repository that wouldn't be available to all: for example the Perl dependency trees that had one or two low level perl libraries that only appeared in the desktop/client offerings. I do not think that we should be shipping things like the gluster core, but, I think ripping out the dependencies as well is simply going to result in EPEL becoming worthless as Red Hat slowly offers more Add-On channels and pulls in library based dependencies from the bottom of EPEL offered dependency trees. Maybe we need to speak to someone from product management about how Red Hat could make more of these dependencies available in something like the optional channels, with minimal support, so that paying customers get the Red Hat RPMs and the support, and those that don't pay for the additional entitlements just have access to the libraries. As someone working heavily with RHEL and Satellite, while we do import the entirety of EPEL into Satellite we only move the RPMs into a used channel that we specifically want to use. It's a little extra work but does also mean that we control our own bake off period. Essential with 1000s of servers. Mark _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
