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

[Kevin Fenzi]

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. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120526/5b995e17/attachment.sig>