[arch-dev-public] News item: /lib removal - Was: heads up: /lib removal

[Allan McRae]

On 11/07/12 11:32, Dan McGee wrote:
> On Tue, Jul 10, 2012 at 5:26 PM, Allan McRae <allan at 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).

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