On Fri, May 25, 2012 at 5:05 PM, Kevin Fenzi <[email protected]> wrote: > On Fri, 25 May 2012 16:45:39 -0500 > inode0 <[email protected]> wrote: >> On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi <[email protected]> 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
