[lug] Weird glibc upgrade problem

Justin glow at jackmoves.com
Wed Mar 21 18:05:27 MST 2001

This is basically in response to everyone that replied to this original 
post. I was actually wondering how exactly other programs relied on 
glibc. Now I know, and obviously explains why most everything was 
broken. I know you're are supposed to use the upgrade procedure when 
using rpm but we did try that originally. All that kept happening was a 
bunch of dependency errors and we could never get it to go thru 
correctly. That is was brought up the idea of removing then re-
installing glibc (obviously a bad idea). I had problems upgrading the 
glibc on one of my redhat boxes a while back too. I did use the upgrade 
flags but it still complained about dependencies, eventually I got it 
to work but it was such a pain. I just don't get how redhat can put up 
these upgrades to packages and just say rpm -Uvh them and you're all 
set. I rarely am able to do just that without any catches or problems 
that have to be worked out. Maybe I'm just not doing something right 
but rpm's have always given me trouble...

Thanks for all the input,


> On Wed, Mar 21, 2001 at 01:11:18PM -0700, Justin wrote:
> > Has anyone else come across this nonsense? At first I thought I 
> > messed something up somewhere along the line. Until today when my 
> > friend ran into the same thing, but with a different package 
> > same packages. I don't understand how trying to remove glibc could 
> > result in such a disaster as this. Anyone thoughts?
> To a degree, I'm going to sound harsh, but it's unintentional. Please 
> take it personally.
> Short answer: You could have made a bigger mistake in your processes, 
but I'm
> not sure how. To give you a rough idea of how bad the error was, I'm 
going to
> use Windows land examples. Imagine if MS actually provided an upgrade 
> kernel32.dll, and ONLY this dll. Now, if you were to try and install 
it, you
> wouldn't remove the current one under Windows, and then copy the new 
one in.
> You'd do it outside of Windows. Otherwise, your entire system would 
crash, and
> you would be completely unable to even start Windows.
> Effectively, this is what you did to Linux. glibc is used by every 
> application on the system, from the littlest ls up to the biggest 
gnome app.
> Unless your application was statically linked, you've just them all 
down. And
> most apps are not statically linked, unless specifically compiled 
that way.
> Proper steps are to use the upgrade options (-U under RH and KRUD), 
not to
> remove then install. That's the only safe way to upgrade a package as 
major as
> glibc.
> -- 
> Michael J. Pedersen
> My GnuPG KeyID: 4E724A60        My Public Key Available At: 
> My GnuPG Key Fingerprint: C31C 7E90 5992 9E5E 9A02 233D D8DD 985E 
4E72 4A60
> GnuPG available at http://www.gnupg.org
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

glow at jackmoves.com

More information about the LUG mailing list