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 <tbowling(a)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 <nkadel(a)gmail.com>
> wrote:
>
>> On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen <smooge(a)gmail.com>
>> wrote:
>> > On 11 April 2018 at 10:02, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>> >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy <
>> abokovoy(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>>
>
>