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@localhost root]# python -c "import os; print os.uname()[4]"
i686
[root@localhost root]# rpm -q yum
yum-0.9.3-1
[root@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@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@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@localhost root]#
And on the yum host from header.info
[g001581@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@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@xxxxxxxxxxxxx
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@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
>
>
