Thoughts from last meeting

[inode0]

On Fri, May 25, 2012 at 5:05 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Fri, 25 May 2012 16:45:39 -0500
> inode0 <inode0 at gmail.com> 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.
>
> So, you would suggest dropping the ha and lb products from overlap?
> Or making it so no channels can overlap?

My general preference as a consumer of both RHEL and EPEL would be in order:

1 - EPEL does not conflict with RHEL + Layered Products (all Layered Products)

I know that holds some important things back that lots of folks benefit from.

2 - EPEL does not conflict with RHEL base packages (base being loosely
defined as what comes with a standard RHEL subscription, so would in
the case of RHEL6 include the optional channel for example).

This would cause issues when using RHEL and Layered Products in spots.

Both of those preferences are either all or nothing with respect to
EPEL's treatment of Layered Products. In 1 Layered Products are off
limits in EPEL, in 2 they are all fair game. This is easy for EPEL
consumers to understand either way.

I would be really happy also with EPEL doing 1 for its primary
repository but also providing a secondary repository where all Layered
Products can be trumped by EPEL versions. Separating those conflicts
into a secondary repo would be a big help to EPEL's downstream users I
think.

People wanting no RHEL conflicts can have that using the primary EPEL
repo only. People using only RHEL without any Layered Products can use
both EPEL repos to get access to bits of Layered Products that are
helpful via EPEL. People using RHEL with Layered Products wanting EPEL
support not affecting Red Hat supported components can restrict their
use to the primary EPEL repo. The only complicated use case would be
RHEL users with Layered Products wanting bits from the EPEL secondary
repo, that group would need to be careful. I think the vast majority
of EPEL consumers could just turn on or off their preferred
combination of the two EPEL repos and go about their business conflict
free.

John