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:
>
> ================
> 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