On Thu, Jan 14, 2010 at 09:21:11PM -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: > >> > >> ================ > >> 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. > Yep. If the alternative is going to take us into the realm of not having certain packages in EPEL because something it depends on is in a layered product and not in the layered products themselves then that option is doesn't make much sense for us.
-Toshio
pgpJEKByWWFCx.pgp
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
