[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,
Justin
> On Wed, Mar 21, 2001 at 01:11:18PM -0700, Justin wrote:
> > Has anyone else come across this nonsense? At first I thought I
just
> > messed something up somewhere along the line. Until today when my
> > friend ran into the same thing, but with a different package
manager,
> > 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
don't
> 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
to
> 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
single
> 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:
wwwkeys.pgp.net
> 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
www.jackmoves.com
More information about the LUG
mailing list