Niels de Vos <devos(a)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