Why don't they "provide it universally in RHEL?" -- WAS: Thoughts from last meeting

[inode0]

On Sat, May 26, 2012 at 1:39 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Fri, 25 May 2012 18:05:38 -0500
> inode0 <inode0 at gmail.com> wrote:
>> On Fri, May 25, 2012 at 5:36 PM, Bryan J Smith <b.j.smith at ieee.org>
>> wrote:
>> > On Fri, May 25, 2012 at 5:45 PM, inode0 <inode0 at 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.

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?

John