[lug] Weird glibc upgrade problem

rm at mamma.varadinet.de rm at mamma.varadinet.de
Wed Mar 21 13:37:59 MST 2001


On Wed, Mar 21, 2001 at 01:28:10PM -0700, Michael J. Pedersen wrote:
[...]
> 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.

Yes, but in contrast to MS-OSs one doesn't _have_ to remove a lib/dll
to add a new one. The Linux dynamic loader is perfectly capable of handling
different versions of the same library. 

> 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.

this only affects programs started _after_ the library disapeared.
ld.so opens the library and memory-maps it. Once an application loaded
it you can remove the libraries file (unlink will only decrease the link
count of the inode. As long as the file is mmaped the application can
access it).

So the 'unfortunate' part was the uninstall instead of just an install
of the new version.

> 
> 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.

Being a Debian user myself i have a question: can one realy remove a package
on which so many others depend. Debians dpkg tool would flood the console 
with warnings and refuse to proceed unless you told it to ignore all 
dependencies ...

 Ralf 


> 
> -- 
> 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



More information about the LUG mailing list