On Fri, 25 May 2012 18:05:38 -0500
inode0 <inode0@gmail.com> wrote:

> On Fri, May 25, 2012 at 5:36 PM, Bryan J Smith <b.j.smith@ieee.org>
> wrote:
> > On Fri, May 25, 2012 at 5:45 PM, inode0 <inode0@gmail.com> wrote:
> >> I don't see any reason for them to just remove it from EPEL while
> >> not providing it universally in RHEL.
> >
> > Define "universally"? *I can understand people wondering how Fedora
> > will handle details. *That's difficult enough at times.
>
> The context here is important. I am questioning the policy of allowing
> Red Hat channel owners a veto power over EPEL maintainers in cases of
> a package Red Hat provides for some architectures but not for others.
> I don't really see any harm in EPEL providing it for architectures
> that Red Hat doesn't provide it for and Red Hat has the choice to add
> it to the missing architecture which would in effect remove it from
> EPEL. There may be problems I don't see, that is why I asked what
> motivated the veto policy.

Ah, I think I worded things poorly... I'll try and come up with a
better way to say it.

I was not intending the policy of shipping a package in EPEL that
exists in RHEL for the purpose of providing it for arches that RHEL
does not ship the package to be "trumped" by channel owners, but rather
be a seperate bit.

ie, say package foobar is available in the foobar channel in RHEL, but
also shipped in epel (possibly with a different version). foobar
channel owners get grief from that and ask epel to stop doing that. If
foobar is available only in say a x64_64 option from channel foobar,
then in my mind epel could still ship it for the purposes of providing
it in other arches. However, it might need to downgrade it to the
version in foobar channel or otherwise sync it up.

I'll try and think of a way to re-write that so it makes more sense.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Sat, 26 May 2012 14:14:12 -0500
inode0 <inode0@gmail.com> wrote:

>
> This is messy.
>
> OK. I'm on board now with the anticipated grief source although this
> exact situation causes EPEL users who want to pin their systems to Red
> Hat provided packages when they exist to be caught in the crossfire
> too. My interest is more about protecting those users of EPEL from
> unintended support issues.
>
> So I think you have a good plan for this case in mind.
>
> What about the case where RHEL provides it for all arches? Are you
> going to remove it from all arches in EPEL if a channel maintainer
> asks for it to be removed?

I would say no, since we aren't doing that in base RHEL... but I guess
there could be some case. I just don't know off hand.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list