Niels de Vos wrote: > They are not under the "os" directory where most packages live: > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/ > It may not be a problem for binary derivatives of RHEL if they don't provide > glusterfs packages. > But this may be a problem for people who use the Red Hat Storage bits.
Far be it from me to interpret policy, so I'll just point how this comment nails the reality, and let others with the project decide. I.e., ask yourself ... Is the Fedora Project's EPEL just for community "EL Rebuilds" and derivatives? Or is EPEL for all, including the customers of the Fedora Project's sponsor, Red Hat? Alan Pevec wrote: > Why do they need to have EPEL repo enabled? Doesn't that make them > unsupported? Again, here's the reality, and I'll let others with the project decide ... Yes, major Red Hat accounts tap EPEL, often bringing in the the EPEL YUM repository into their RHN Satellite Server. It saves them having to build all sorts of upstream community solutions. And yes, of course, these components in EPEL are _unsupported_. But they remove not just a lot of the overhead of customers building-their-own, but the policies and other advantages of the Fedora Project itself can be leveraged. Leaving them in EPEL means that Red Hat customers now must clone and segment out the conflicting bits. Although many accounts end up cloning channels into "internal releases" so the test EPEL components, it's still going to add to their workload. And with that all said, as I understand it, one of the reason for the EPEL guidelines were so Red Hat customers would not have conflicting components in EPEL that are also available from RHN. Two, conflicting sets of packages on the same server, that is really, really _unsupported_, and causes headaches for Red Hat services and support. I.e., sometimes it takes a bit before this "root cause" is discovered (first hand experience speaking here). ;) Which brings me to the final point, which is non-technical ... Marginalizing Red Hat customers, ones who fund a lot of what Red Hat does upstream (and downstream as well), is not probably the best move for the longevity of the Fedora Project, or "EL Rebuilds" who rely on Red Hat's continued funding. This should be obvious to many here, but I understand there might be some community members here who may not see this immediately (hence why I'm pointing it out). Again, far be it from me to interpret policy, but to me, if it is in a RHN channel, it makes more sense for downstream "EL Rebuilds" to fetch the source, rebuild, and include it in their redistributions. Any time one goes down the route of asking, "well, is this really OS?" ignores the fact that it is available from RHN, and will affect customers of Red Hat. Red Hat is more than an open source OS, and even more than just platform components. Otherwise it is going to get really ugly for Red Hat customers, and EPEL will lose its value with them. That's really a case no one should want to see, as it will affect everyone, not just Red Hat and its customers. Of course, I could be biased. ;) -- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
