News item: /lib removal - Was: heads up: /lib removal
 

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

News item: /lib removal - Was: heads up: /lib removal
 

On Tue, Jul 10, 2012 at 5:26 PM, Allan McRae <allan@archlinux.org> 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).

> 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