Re: new up2date is broken

[Eric Hagberg morganstanley com]

glibc is a problem because up2date can't grab the i686/i386 rpm it needs
to update, and it has to have that at the same time it is updating the
x86_64 version of the rpm. That's why there is a conflict.

It sees that it is about to upgrade glibc-common and leave the ia32
version of glibc un-upgraded and that's the dependency issue.

The responsible individual said on Thursday (via bugzilla) that this would
be fixed in a day or two.

The workaround is to manually pull the latest glibc and glibc-devel rpms
via the rhn website and then do an "up2date --get" for the other glibc
rpms and upgrade them via rpm.

I'd also noticed a bug that if you do this manually, for some reason the
header files in glibc-devel from the i386.rpm get installed instead of the
x86_64.rpm ones, and that needs to be remedied by forcing an additional
installation of the glibc-devel*.x86_64.rpm (or face problems compiling
things).

On Fri, 29 Aug 2003, Bill Broadley wrote:

> My up2date is still broken.
>
> I can't get eclipse or glibc to upgrade, I get something like:
> Unresolvable chain of dependencies:
> eclipse  2.1.0-15                        requires libORBit-2.so.0
> eclipse  2.1.0-15                        requires libbonobo-activation.so.4
> eclipse  2.1.0-15                        requires libgcj.so.4
> eclipse  2.1.0-15                        requires libgnomevfs-2.so.0
> eclipse  2.1.0-15                        requires liblinc.so.1
> glibc-2.3.2-69                           requires glibc-common = 2.3.2-69
>
> It seems as if up2date doesn't think that glibc-common-2.3.2-77 will
> not replace glibc-common-2.3.2-69.
>
> Does anyone know a work around?
>
> This is on a dual opteron btw, fully up2date except for the above.
>
> Does anyone know of a workaround?  Maybe a source of glibc-*2.3.2-77 rpm's
> that I could --force --nodeps?  I've done nothing but the standard up2date
> runs since I installed it (the beta-1 version).
>
> Any help appreciated.