[Yum] Re: Yum error question

[Jim Wildman]

I just realized that I have seen another variation of this bug.  This is
on an IBM x335 Xeon machine running RedHat AS 2.1

[root at localhost root]# python -c "import os; print os.uname()[4]"
i686

[root at localhost root]# rpm -q yum
yum-0.9.3-1

[root at localhost root]# rpm -q --qf "%{name} %{version} %{release}
%{arch}\n" `rpm -qa | grep glibc`
glibc 2.2.4 26 i686
               ^^^^
glibc-devel 2.2.4 26 i386
glibc-common 2.2.4 26 i386

[root at localhost root]# yum update glibc
Gathering package information from servers
Getting headers from: Red Hat Linux Advanced Server 2.1 base
Getting headers from: Red Hat Linux Advanced Server 2.1 updates
Finding updated packages
Downloading needed headers
getting lynx-0-2.8.4-18.1.i386.hdr
getting shadow-utils-1-20000902-9.7.i386.hdr
getting fileutils-0-4.1-10.1.i386.hdr
getting kernel-summit-0-2.4.9-e.12.i686.hdr
glibc is installed and the latest version.

[root at localhost root]# yum update
Gathering package information from servers
Getting headers from: Red Hat Linux Advanced Server 2.1 base
Getting headers from: Red Hat Linux Advanced Server 2.1 updates
Finding updated packages
Downloading needed headers
Resolving dependencies
package glibc needs glibc-common = 2.2.4-26 (not provided)
package glibc needs glibc-common = 2.2.4-26 (not provided)
[root at localhost root]# 

And on the yum host from header.info
[g001581 at ino0l001 up2date]$ grep glibc headers/header.info 
0:glibc-common-2.2.4-31.7.i386=glibc-common-2.2.4-31.7.i386.rpm
0:glibc-devel-2.2.4-31.7.i386=glibc-devel-2.2.4-31.7.i386.rpm
0:glibc-2.2.4-31.7.i386=glibc-2.2.4-31.7.i386.rpm

and
[g001581 at ino0l001 up2date]$ rpm -qp --qf "%{name} %{version} %{release}
%{arch}\n" glibc-*.rpm
glibc 2.2.4 31.7 i386
glibc-common 2.2.4 31.7 i386
glibc-devel 2.2.4 31.7 i386

So the "real" problem is that my update tree does not include an i686
glibc.  yum won't upgrade the older i686 package to the newer i386
package.  Is that a bug or a feature? :-)

------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE                                jim at rossberry.com
http://www.rossberry.com

On 25 Feb 2003, seth vidal wrote:

> On Tue, 2003-02-25 at 09:38, Tom Diehl wrote:
> > On 25 Feb 2003, seth vidal wrote:
> > 
> > > I think I just realized what's going on, maybe
> > > 
> > > the custom-tag kernel is i686, isn't it?
> > > 
> > > so yum is doing the following:
> > > 
> > > it's seeing the i686 kernel and the other athlon kernels, it's saying,
> > > what's the best you got, name+arch.
> > > 
> > > then it's comparing the available pkg of 2.4.18-24.7.x to the -17.7x
> > > athlon kernel and saying - look at that the new kernel is newer,
> > > ignoring the i686 custom tag.
> > 
> > Looks like you might be right. I did not realize that installing a
> > different arch would mess with yum. Sorry.
> 
> it shouldn't. It's a bug. I've got a test fix.
> 
> 
> > 
> > [root at octopus root]# rpm -q --qf "%{name} %{version} %{release} %{arch}\n" kernel
> > kernel 2.4.18 24.7.x.1.nano.tjc i386
> > kernel 2.4.7 10 athlon
> > kernel 2.4.18 17.7.x athlon
> > kernel 2.4.9 21 athlon
> > So does this mean that the answer here is to handle the kernel upgrades
> > by hand or do you still consider this a bug?
> 
> 
> I've figured out how to fix it - I'll have a tarball shortly.
> 
> Thanks for finding this case, it would have bit others eventually.
> 
> -sv
> 
>