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 _______________________________________________ epel-devel mailing list [email protected] http://lists.fedoraproject.org/admin/lists/[email protected]
