Thoughts from last meeting

[inode0]

On Mon, May 28, 2012 at 11:42 PM, Stephen John Smoogen <smooge at gmail.com> wrote:
> On 28 May 2012 20:16, inode0 <inode0 at gmail.com> wrote:
>> On Mon, May 28, 2012 at 6:53 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
>>> On Fri, May 25, 2012 at 04:45:39PM -0500, inode0 wrote:
>>>> On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>>>>
>>>> > Anyhow, thoughts? concerns?
>>>>
>>>> As an EPEL consumer I find this all rather confusing. I don't want to
>>>> have to know which layered products are protected and which aren't. I
>>>> think I'd rather live with a simpler uniform policy regarding layered
>>>> products.
>>>>
>>> As a non-administrator of RHEL I find it confusing too.  I don't know what
>>> fee structure and other non-repository divisions occur between base RHEL and
>>> layered products and whether they are the same for all layered products or
>>> only some.
>>
>> The nature of layered products is changing as RHEL is offered as more
>> of an a la carte product now. While EPEL including something like
>> puppet isn't such a big concern to me as it is a small component of a
>> larger offering from Red Hat, EPEL providing piranha + ipvsadm which
>> comprise the Load Balancer Add-On is a much bigger concern to me. I
>> don't really think EPEL should put Red Hat in the position of having
>> to ask for it to be removed. So unless we know that including such
>> things is fine with Red Hat in advance I think we should exclude them
>> as EPEL providing complete "layered products" or "Red Hat Enterprise
>> Linux Add-Ons" seems like crossing a line we shouldn't cross to me.
>
> Well then the only way I can see to meet your point would be to stop EPEL.

I'm not sure it is that dire. Do we know if Red Hat cares about EPEL
providing complete RHEL Add-Ons? If they don't then my concern is
gone.

> There are very very few packages left after the conflicting packages
> and their requirements are pulled. You can't include any of the other
> configuration management tools because they also use pulled in
> libraries (augeus and such). Anything with Perl dependencies are
> pulled from other items in the layered products. And since many of the
> items that would be left are supported by maintainers whose main
> packages would be pulled.. I doubt they would want to support those
> eithers. It quickly becomes a cascade of pulls to the point where it
> is not worth keeping going.

I can imagine pulling in libraries needed as dependencies to be viewed
as ok while completely replacing RHEL Add-Ons not being viewed as ok.
There may be some middle ground even if EPEL doesn't provide RHEL
Add-Ons.

John