On Sat, Apr 14, 2018 at 2:04 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On 04/11/2018 03:13 PM, Nico Kadel-Garcia wrote: > >> EPEL is a default, critical requirement for many tools, including Chef >> and mock. Many environments running RHEL or CentOS 6 could not be used >> without EPEL's plethora of useful tools. RHEL channels can conflict >> with each other because they are enabled on an individual host, case >> by case basis. I think, from old experiences, that having *anything* >> in EPEL that overlaps with any RHEL published channel is begging for >> pain. > > There's a number of problems with EPEL saying they won't conflict with > any channel RHEL "publishes". For one, I don't know of any such list of > channels and all the rpms they contain. Additionally, that would mean > likely removing things like Chef and mock, because I suspect there's > some channels out there with those. That's why I was very careful to say "RHEL published channel". If you build your own private yum repository, well, it's your responsibility to set your policies with it. To the best of my ability to discover, chef is not in *any* published yum repository. The installation procedures for it on RHEL and CentOS are "run this script to get the right RPM" based. For mock, it's published in EPEL, not in the base RHEL channels. So it's completely consistent for it to rely on EPEL itself. >> It may cause pain to current RHEL ansible users, but I think that the >> EPEL package needs to be renamed to something like "ansible25" to >> avoid conflicts with the RHEL channel. > > I don't think thats practical / desirable. > > kevin I'd agree that it would have been easier to do up front. On further thought, say call it "ansible-rhel" to resemble the way mysql and java are published as distiinctly named sets of tools for different published releases from different authors. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
