On Fri, 25 May 2012 18:05:38 -0500 inode0 <[email protected]> wrote: > On Fri, May 25, 2012 at 5:36 PM, Bryan J Smith <[email protected]> > wrote: > > On Fri, May 25, 2012 at 5:45 PM, inode0 <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
