From The Compiler, 5 Years ago, written in Plain Text.
Embed
  1. A patched version of pacman is now in [testing] that will detect all the
  2. issues reported so far that resulted in failed updates.   Users of the
  3. [testing] repo who last updated in the three days between the kmod
  4. update and the glibc update may still run into issues, but "pacman -Sy
  5. pacman && pacman -Su" will prevent that.
  6.  
  7. Here is a (very draft) news item.  I think it provides complete update
  8. instructions for people using the "stable" repos.
  9.  
  10.  
  11.  
  12. Removal of /lib directory
  13.  
  14. All files in the /lib directory have been moved to /usr/lib and now /lib
  15. is a symlink to usr/lib.  During this update, pacman will identify a
  16. conflict in the /lib directory.  In the simplest case, this is worked
  17. around by doing
  18.  
  19. pacman -Syu --ignore glibc
  20. pacman -Su
  21.  
  22. When additional package depend on having a newer version of glibc than
  23. is currently on your system and these also have files in /lib (e.g.
  24. older versions of gcc), then and extra step will be necessary.  For example:
  25.  
  26. pacman -Syu --ignore glibc gcc
  27. pacman -Sd gcc
  28. pacman -Su
  29.  
  30. Only do the -Sd step if really necessary.  Pacman will warn you about a
  31. conflict in /lib on the -Su step if it is.
  32.  
  33. If the "pacman -Su" step reports a conflict in /lib, you will need to
  34. look at all the files in /lib and determine which ones are not owned by
  35. glibc.  This is achieved by "pacman -Qo /lib/*".  You will need to move
  36. any files not belong to glibc to /usr/lib (either through fixing their
  37. package or manually moving unowned files).  There should be no
  38. subdirectories in /lib either.
  39.  
  40. Finally, NEVER use pacman --force (-f) for the glibc update.  That will
  41. result in a broken system.