Thoughts from last meeting

inode0 inode0 at gmail.com
Fri May 25 21:45:39 UTC 2012


On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> So, at our last meeting:
>
> http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2012-05-23-22.12.html
>
> There seemed to be a fair bit of push to change our policy from:
>
> "EPEL6 will not ship any packages that have src.rpms on public mirrors
> under 6* directories with the following exception: If the binary rpm is
> only shipped in some arches in RHEL, EPEL may ship a package as close
> as possible to the RHEL version with a leading package Release of 0.
> (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly
> with the RHEL src.rpm where possible)."
>
> to
>
> "EPEL6 will not ship any packages that have src.rpms on public mirrors
> under 6-Server, 6-Server-ha, 6-Server-optional, 6-Server-lb, except

What is the logic behind protecting only these two layered products?
Seems if we are ignoring other layered products we might as well just
ignore all layered products and greatly simplify things.

> packages missing in one of our supported arches may be shipped by EPEL,
> but must abide by
> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages.

I really like this policy.

> Additionally, EPEL will drop packages that overlap with other RHEL
> channels/layered products on request of those channel owners"

What is the concern here? How would this impact the owners of the
layered product channels?

> Is that what folks in that meeting were thinking (I wrote up the
> statement that I thought people were agreeing to, I could well have
> messed up people's intent)?
>
> So, what do people think of the above?
> Any amendments? Problems that we should note or might sway people to
> want to adjust it?
>
> This gives channel owner/layered products people the ability to decide
> if overlaping with epel for their specific channel use/case makes sense
> or not, or if it would cause problems for them.

The RHEL owner can provide if for all channels and that will remove it
from EPEL. I don't see any reason for them to just remove it from EPEL
while not providing it universally in RHEL.

> 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.

John




More information about the epel-devel-list mailing list