Joe Julian wrote:
Even that's not always feasible, like when RHEL suddenly
started including the RHGS-only gluster client.
Well, that's a "complex" argument.
Initially: The Storage Gluster client was in a RHEL _child_ channel
at first, which was _not_ "recognized" as being "off-limits" by EPEL.
Then: The Storage Gluster client was moved into the RHEL base channel
itself with a specific RHEL 5 and 6 Update, so suddenly "conflicting"
overnight.
So it's more of the definition of "conflict" is a "complext"
argument.
E.g., if a customer had Storage Gluster, it was _always_ conflicting,
even when in the _child_ channel, even if _not_ "recognized" by EPEL
as a "conflict."
Which goes to ...
Kevin Fenzi wrote:
True. I recall someone getting on my case about the 'never'
when
there's often overlap because RHEL does something and we don't
notice it right away.
Back through 2011, every Red Hat major account "trusted" EPEL not to conflict.
But by 2013, virtually all Red Hat major accounts (at least all I was
exposed to) _outlawed_ EPEL from being enabled at all, because of the
endless conflicts with countless, various Red Hat products.
So ... today, in 2016, it doesn't really matter. Back in 2012, I was
more worried about EPEL becoming something customers cannot enable.
But that's now the reality.
I.e., Most Red Hat customers _never_ enable EPEL on systems, and they
just "temporary enable" on very "select" systems for niche purposes.
E.g., if you are a Red Hat customer who has any Red Hat product that
is not "protected" from conflicts with EPEL, you will have a mess if
you enable it ... so none of them do.
Just how it is. No sense in reversing things now, unlike back in
2012. Red Hat customers, especially major accounts with at least a
few add-ons, just cannot flirt with using EPEL.
It's become a dev and niche repo for them. Again, that's fine now, in
2016. If there was a way to avoid this, this was something that
should have been done back in 2012. So I don't see any need to change
course, today.
-- bjs
--
Bryan J Smith -
http://www.linkedin.com/in/bjsmith