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: >> >> ================ >> found this by first looking for conflicts in packages and then doing a >> reverse walk with >> for i in $( cat file-of-conflicts ); do repoquery --disablerepo="*" >> --enablerepo=epel --qf='%{NAME}' --whatrequires $i; done >> > Wait a minute.... So the first list is conflicts with with > RHEL layered products. We're saying, these packages are in our new > definition of RHEL and thereforewe need to drop them. I'm with you so far. > > 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. Personally I think the point is we have to rewrite the rule to basically if its in ftp://ftp.redhat.com/pub/redhat/linux/enterprise/*/os/ we dont' replace/overwrite.. but otherwise caveat empor. Especially since one of the things EPEL allows for RH is to have packages that they know are packaged to standards, work with EL (at somepoint of time) that they can then pull back into layered products. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
