Re-adding epel-devel as I was previously not a member and received a rejection notice.
Thank you, Terry Bowling Sr. Technical Product Manager - RHEL Systems Mgmt Red Hat, Inc. On Sat, Apr 14, 2018 at 6:58 AM, Terry Bowling <tbowl...@redhat.com> wrote: > Hopefully I can help provide some clarity on this topic, though there is > no easy answer to all aspects. We worked with the Ansible product team to > bundle the Ansible Engine product with the RHEL Subscription. This wording > is important to address the following which we have learned over the past > year are critically important. > > - Ansible Engine is a distinct and separate product, with *separate > channel / repo*, lifecycle, release cadence, and support policies. > - Make AE ubiquitous and easily accessible - full support comes with a > subscription > - As a separate product bundled with RHEL, it is *not* RHEL official > content and can go back into EPEL (which was very important). > - The version of Ansible previously provided in RHEL Extras is now > officially deprecated > > Changing the package name in one channel does not make all of the problems > go away. There are still Require and Provides metadata tags that would > inevitably cause future conflicts. And probably other issues that I cannot > think of at the moment. > > So if a user decides to enable the AE & EPEL channels, then I guess they > could use repo priorities to decide which version is more important to > them. If we decide for them, we will be wrong 50% of the time. > > If they are comfortable with EPEL content, I would assume they would > simply not enable the AE channel and problem is solved. At least we are > not making them choose between Extras and EPEL now. With that said, is > this still a problem? > > > Thank you, > Terry Bowling > Sr. Technical Product Manager - RHEL Systems Mgmt > Red Hat, Inc. > > > On Wed, Apr 11, 2018 at 6:13 PM, Nico Kadel-Garcia <nka...@gmail.com> > wrote: > >> On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen <smo...@gmail.com> >> wrote: >> > On 11 April 2018 at 10:02, Nico Kadel-Garcia <nka...@gmail.com> wrote: >> >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy < >> aboko...@redhat.com> 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@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
