Odi's astoundingly incomplete notes

For a long time Gentoo had this exotic layout (same for /usr/lib32):

lrwxrwxrwx   1 root root     5 Aug 31 09:59 lib -> lib64
drwxr-xr-x   2 root root  4096 Aug 31 09:59 lib32
drwxr-xr-x  15 root root 12288 Oct 15 18:06 lib64

This is now changing to what most other distros are doing:

drwxr-xr-x  14 root root       4096 Nov  9 11:45 lib
drwxr-xr-x  10 root root      12288 Nov 11 09:28 lib64

/lib32 becomes the new /lib and /lib64 hold only 64bit specific files. All generic files now go into /lib (and no longer /lib64). Nobody hard-wires /lib32 anymore.

The migration is pretty smooth with the app-portage/unsymlink-lib utility. On all my systems it was enough to do this:

emerge -1v app-portage/unsymlink-lib
unsymlink-lib --analyze
# check the output for orphaned files and clean up, run analyze again
unsymlink-lib --migrate
unsymlink-lib --finish
eselect profile set 1  (or whatever you chose)
emerge -1av gcc
emerge -1av libtool binutils
source /etc/profile
emerge -1av glibc sandbox
# check for remaining packages
emerge -1pvD /lib32 /usr/lib32 /usr/lib/llvm/*/lib32

I encountered only some small catches:

1. If you maintain a binhost (one that builds and serves binary packages for others), make sure to also rebuild sys-apps/baselayout.
2. If you install from a binhost, make sure that the binhost is migrated first, and that all clients migrate away from /lib32 immediately. Never let a new client (no /lib32) update from an old binhost (with /lib32).
3. The ancient app-emulation/emul-linux-x86-compat has /lib32 and /usr/lib32 files but is not available anymore. This forced me to keep the symlink /lib32 -> /lib on these servers (they run old Oracle versions).
4. nagios-core's CGI binaries move from /usr/lib to /usr/lib64 and their path is referenced in the Apache configuration.


posted on 2020-11-13 14:32 UTC in Code | 0 comments | permalink