On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > On 11 April 2018 at 10:02, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote: >> >>> I'm not in Ansible engineering or product management so take this with a >>> grain of salt. My understanding is that cadence of Ansible releases and >>> its aggressiveness in API changes makes it a bit less suitable to follow >>> a traditional RHEL 7 release cadence. A separate product channel allows >>> them to update packages at own cadence. >>> >>> I wonder how re-packaging for CentOS targets could happen with this >>> approach and probably moving it back to EPEL7 is indeed something that >>> makes more sense. >> >> Wouldn't a separate RHEL channel for a separate product, such as >> ansible, mean a separate channel for CentOS to avoid precisely this >> confusion? Mixing it into EPEL and having it on a separate RHEL >> channel would be *bad* for anyone who activates that separate channel. >> They'd have to filter it out of EPEL to ensure that the streams don't >> get crossed on any updates from Red Hat. I understand that this is one >> of the main reasons EPEL never carries packages that overlap with RHEL >> published software. > > It is a lot more nuanced than that. EPEL builds packages that do not > overlap with the following channels: > > > rhel-7-server-extras-rpms/ > rhel-7-server-optional-rpms/ > rhel-7-server-rpms/ > rhel-ha-for-rhel-7-server-rpms/ > rhel-server-rhscl-7-rpms/ > > These are chosen because they were the base set originally and other > channels which might be available can have items which conflict with > each other. This means that EPEL can conflict with somethings inside > of "RHEL" but so can things are in "RHEL". 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. 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
