On Fri, Jan 15, 2010 at 2:06 AM, David Juran <djuran(a)redhat.com> wrote:
On Thu, 2010-01-14 at 21:21 -0700, Stephen John Smoogen wrote:
> On Thu, Jan 14, 2010 at 8:43 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
> > On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote:
> >
> > But why the second list? If the package is in RHEL, then we need to check
> > the second list and see if they can build/work with the version in RHEL,
> > right? Not outright drop?
>
> The packages are in channels that are layered onto RHEL and not
> available to customers who have not bought those products. Only the
> SRPMS are available. Thus building those packages would be impossible
> for someone who is trying to build stuff on CentOS or in the build
> system. So basically you have to pull them because you can't build
> them IF you following the rule as written.
I think we've been through this before, but if EPEL would ship the same
version that Red Hat does of the layered products then there wouldn't be
any conflict for those who have the layered product and the one's who do
have the layered product can still enjoy the package. Or am I missing
something here?
It would conflict because you have essentially the same package, same
version, same release, etc. but from two different sources. This is
what the yum-priorities plugin exists to solve but it is not known to
work with RHN so CentOS users are fine, but RHEL users are hosed.
Also, doesn't CentOS ship re-builds of the layared products?
Yes, they do.
<SNIP>
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\
www.asciiribbon.org - against proprietary attachments