[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Packages duplicated between EL-5 sub-channels and EPEL

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

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


Attachment: pgpwuCozkhDpT.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]