On Fri, Jan 15, 2010 at 2:06 AM, David Juran <[email protected]> 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 <[email protected]> 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
