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

[Allan McRae]

On 08/07/12 03:25, 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.
> 


So...  this upgrade has been more fun than expected.  At the moment
there appears to a "limitation" in pacman so I would recommend updating
like:

Step 0) open a root shell - this can be used to recover if anything goes
wrong

Step 1) run:
pacman -Qo /lib/*
Deal with (either via updating from the repo or rebuilding) anything not
owned by glibc

Step 2) run:
find /var/lib/pacman/local -name files | xargs grep "^lib/$"
This should only return glibc.  If not, rebuild those packages not to
own the /lib directory

Step 3) pacman -Syu


If something goes wrong (you will see a message like "call to execv
failed"), use your root shell to do:
/usr/lib/ld-2.16.so /bin/rm -r /lib
/usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib



Note that all this should have been unnecessary and the instructions
given by falconindy should have been enough.  But there appears to be a
genuine pacman bug in conflict checking where it ignores other packages
owning a directory when it checks if it can be removed.  Hopefully this
can be fixed soon...  There may be something else going on with here
too, but we are unsure as of yet.

Note that pacman will detect when there are files in /lib that do not
belong to glibc before upgrade, just not if some other package owns /lib
only (with no files).   So all the cases I tested (folder and files in
/lib, both owned and unowned by packages) do not result in the error.

Allan