On 11/07/12 11:32, Dan McGee wrote: > On Tue, Jul 10, 2012 at 5:26 PM, Allan McRae <[email protected]> wrote: >> A patched version of pacman is now in [testing] that will detect all the >> issues reported so far that resulted in failed updates. Users of the >> [testing] repo who last updated in the three days between the kmod >> update and the glibc update may still run into issues, but "pacman -Sy >> pacman && pacman -Su" will prevent that. >> >> Here is a (very draft) news item. I think it provides complete update >> instructions for people using the "stable" repos. >> >> >> >> Removal of /lib directory >> >> All files in the /lib directory have been moved to /usr/lib and now /lib >> is a symlink to usr/lib. During this update, pacman will identify a >> conflict in the /lib directory. In the simplest case, this is worked >> around by doing >> >> pacman -Syu --ignore glibc >> pacman -Su >> >> When additional package depend on having a newer version of glibc than >> is currently on your system and these also have files in /lib (e.g. >> older versions of gcc), then and extra step will be necessary. For example: >> >> pacman -Syu --ignore glibc gcc >> pacman -Sd gcc >> pacman -Su >> >> Only do the -Sd step if really necessary. Pacman will warn you about a >> conflict in /lib on the -Su step if it is. >> >> If the "pacman -Su" step reports a conflict in /lib, you will need to >> look at all the files in /lib and determine which ones are not owned by >> glibc. This is achieved by "pacman -Qo /lib/*". You will need to move > > find /lib -print0 | xargs -o pacman -Qo > is much more effective at helping track down pesky files in > subdirectories (ala catalyst-hook).
I figure that: error: cannot determine ownership of directory '/lib/foo' is a good hint, because these directories need removed too. >> any files not belong to glibc to /usr/lib (either through fixing their >> package or manually moving unowned files). There should be no >> subdirectories in /lib either. >> >> Finally, NEVER use pacman --force (-f) for the glibc update. That will >> result in a broken system. >> >> > > This package tripped me up for a while; what's the expected easy > update path for those of us with it installed? Adding another three > steps like `pacman -Rdd lib32-glibc`, then above commands, then > reinstall seems very crazy to me, but that was the only way I found. > > lib32-glibc /lib/ > lib32-glibc /lib/ld-linux.so.2 lib32-glibc does not have a versioned dependency on glibc anymore so the "pacman -Syu --ignore glibc" should still update it? Do you have [multilib-testing] enabled? Allan
