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
