David Baron a écrit : > On Tuesday 24 April 2007, Aurelien Jarno wrote: >> David Baron a écrit : >>> On Tuesday 24 April 2007, Aurelien Jarno wrote: >>>> David Baron a écrit : >>>>> Package: libc6 >>>>> Version: 2.5-2 >>>>> Severity: critical >>>>> Justification: breaks unrelated software >>>>> >>>>> 1. Upgrade -- balks at symlinks in /usr/lib, asks user to remove them. >>>>> BAD BAD BAD! >>>> What do you mean exactly? Could you please give us the output messages? >>> I have downgraded because more things became broken and a lot of >>> dependencies are shot. The message was to the effect: >>> Duplicate library found .... unsafe to upgrade .... remove, then try >>> again. The libraries sited were symlinks on /usr/ib >>> frist libc.so.0.6, then libdl.so.2, ehtn librt.so.1 (if I remember >>> correctly) >> You should never have such libraries in /usr/lib. No Debian package >> install the glibc libraries in /usr/lib, their place is in /lib, >> otherwise expect the problem you encountered. >> >> This is therefore not a bug of the glibc package, but a problem of your >> system. Closing the bug. >> >>>>> 2. Once these removed, installs. Bash is now unusable--problem is in >>>>> calls from bashrc, bash.bashrc, et al. bash -norc, sh (not login) work. >>>> Well I don't really understand what did you removed. Anyway bash should >>>> work correctly, even with /usr/lib removed. >>> I removed the symlinks requested for removal above. >>> Bash using its rc files no longer worked. >>> Without the rcfiles,as I stated, worked as non-login mode. >>> bash -norc or sh. >>> >>>>> 3. The libc.so.6 synlink it kicked at is replaced. Reinstall will again >>>>> balk. >>>> Which file exactly? Could you give us the full path. >>> Those cited above. >>> >>>>> 4. The other symlinks are needed by ld when building dependent >>>>> programs! 5. Once replaced, builds procede but all built programs >>>>> segfault. >>> Note that I did not simply remove anyting but moved it. First I took off >>> from /lib which of course was catastrohpic. I restored those ans was able >>> to reboot. That is why I say that the script should not ask users to >>> remove anything like that. What must be removed/replaced should be done >>> by the script and this should be thoroughly tested before posting, >>> obviously. This is unstable, ok, but not experimental. >> Wrong. No package put glibc libraries in /usr/lib. If a user does that, >> it is his/her responsability to take care of those files. > > However, 2.5.2 certainly did do so. Maybe the older ones I had there should > not have been but once I took them out, they should not have reappeared!
Wrong again. It's ldconfig which recreate them because you have a copy of the glibc in /usr/lib. This is not new for glibc 2.5-2, its the case since ldconfig exists... Try 'rm -f /usr/lib/*-2.3.6.so'. Again you should not have a copy of the glibc in /usr/lib (*-2.3.6.so files). BAD BAD BAD! > 2.3.6.... does not put a libc.so symlink in /usr/lib but does place symlinks > for librt, libdl. > > Note that if the symlinks are absent, ld will fail looking for them but this > could be a path problem. .so symlinks are needed for ld, but .so.X are not needed and only create problems as you experienced. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
