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
<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.
On CentOS all of the conflicting packages except these two seem to be
available:
perl-Network-IPv4Addr
python-json
I searched for the packages with this query:
repoquery --qf "%{name}" --repofrompath
centos-core,http://ftp.halifax.rwth-aachen.de/centos/5.4/os/i386/ --repofrompath
centos-updates,http://ftp.halifax.rwth-aachen.de/centos/5.4/updates/i386/ $PACKAGE_LIST
Regards
Till