On 08/07/12 23:36, Jan de Groot wrote: > On za, 2012-07-07 at 13:25 -0400, Dave Reisner wrote: >> Hey all, >> >> Allan pushed glib 2.16-2 into [testing] which removes /lib as a >> directory, replacing it with a symlink. A bit of advice... >> >> - In the simplest case, the upgrade can be done as simply as: >> >> pacman -Syu --ignore glibc && pacman -S glibc >> >> - Since nothing is ever simple, if the above still fails on installation >> of glibc (with a somewhat cryptic "/lib exists" error), you'll need to >> figure out what's still in /lib that doesn't belong to glibc. >> Generally this will end up being modules/. pacman -Qo /lib/* will >> pinpoint what needs fixing/removing. Deal with anything that isn't >> owned explicitly by glibc and complete the installation. >> >> It shouldn't need to be said, but I'll mention it anyways: >> >> Do. Not. Use. (the) --force. Obi-wan approves of this. > > I didn't need --force to fuck up my system. When I upgraded like above, > I got file conflicts because of some depmod files in /lib/modules, > combined with an old ancient udev-compat package. I removed udev-compat > and the files, but there were still some empty directories in /lib. > When running pacman -S glibc, pacman didn't detect any file conflicts, > installed the new glibc, told me that it could not extract /lib and then > left my system in a state that couldn't execute a single command > anymore. >
Thanks, that was a case I had missed in patching pacman to detect these conflicts early. These two patches should catch all issues noted so far during the conflict checking stage and prevent these rouge extractions: http://mailman.archlinux.org/pipermail/pacman-dev/2012-July/015678.html http://mailman.archlinux.org/pipermail/pacman-dev/2012-July/015679.html Allan
