Niels de Vos devos@fedoraproject.org wrote:
I think it is important to make a difference between add-on (like High Availability to Red Hat Enterprise Server) and a product (like Red Hat Satellite). IMHO it makes sense to allow EPEL packages with (Build)Requires from the Add-Ons,
Why not just use the add-ons? Especially when they have clearly been in Advanced Server, AS and Advanced Platform and, therefore, EL Rebuilds? Why does EPEL have to now ship them, causing yet another set of conflicts with both Red Hat and EL Rebuild stacks?
When did this view and/or expectation change?
Some examples: RHEL customers that do not have the required add-ons (like HA), would have dependency problems for packages from EPEL that require the cluster infrastructure.
Then customers should do as they always have done ...
Either purchase the RHEL entitlements, or use the EL Rebuilds.
For Fedora EPEL developers/maintainers, Red Hat should provide the necessary entitlements.
I doubt that these packages are useful without the cluster bits.
Exactly! So why is EPEL going there?
RHEL-clones can provide the add-ons as part of their standard distribution, no dependency issues there.
Exactly! So why is EPEL going there?
On most (all?) Red Hat Products (like Red Hat Satellite and Storage) customers are not supposed to install additional applications.
RHN Satellite Server, I largely agree, and that's always been the case. Although I have seen EPEL tapped on RHNS/Spacewalk, but I won't go into that.
But RHN Storage, different story. There has been many customer-facing discussions to the contrary.
The products are mostly contained within their own installation. It make little sense to add EPEL to these servers where a product has been installed.
But it is going to happen, and does.
Therefore, it is possible to allow puppet, glusterfs and the like in EPEL. These packages are part of Red Hat products, and not available in the add-ons. The standard Red Hat Enterprise Server can be enhanced with non-conflicting packages. Does this make sense to others as well?
No, sorry, I have to disagree with most of your statements, especially on the AS/AP components.
-- Bryan
P.S. This is exactly what I was warning about and Seth didn't believe me.
-- Bryan J Smith - Professional, Technical Annoyance