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.
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.
- 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.
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 <nkadel@xxxxxxxxx> wrote:
EPEL is a default, critical requirement for many tools, including ChefOn 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".
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@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
