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 -- de...@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>
>
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Reply via email to