On Fri, 25 May 2012 18:05:38 -0500
inode0 <inode0(a)gmail.com> wrote:
On Fri, May 25, 2012 at 5:36 PM, Bryan J Smith
<b.j.smith(a)ieee.org>
wrote:
> On Fri, May 25, 2012 at 5:45 PM, inode0 <inode0(a)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