No doubt someone will want to rewrite the title of this. :) Anyway, I have (on two machines) util-linux installed with the cryptsetup USE flag. After the update from json-c-0.13.1-r1 to json-c-0.14-r2 (which replaces libjson-c.so.4.0.0 with libjson-c.so.5.0.0) portage no longer works, because the mount command (used by pid-sandbox) fails due to its dependency on libjson-c.so.4.0.0 (again, this will only happen when util-linux has the cryptsetup USE flag set). I think I can recover from this, but the json-c-0.14-r2 ebuild should if (util-linux has cryptsetup support) leave libjson-c.so.4.0.0 around (with instructions to remove later) and require the rebuild of util-linux after the update. See: https://forums.gentoo.org/viewtopic-p-8458398.html
util-linux does not use libjson-c directly. libjson-c probably gets pulled in by libcryptsetup. Rebuilding sys-fs/cryptsetup should resolve the issue. sys-fs/cryptsetup already uses a slot-operator for the dev-libs/json-c dependency, which should trigger an automatic rebuild of the former when the latter is upgraded. As well, the preserve-libs Portage feature should prevent libjson-c.so.4 from being removed until the rebuild occurs. Have you disabled FEATURES="preserve-libs"?
/bin/mount is unable to operate once json-c goes from .so version 4 to .so version 5. --- BEGIN --- ~ # ldd /bin/mount linux-vdso.so.1 (0x00007ffc187d7000) libmount.so.1 => /lib64/libmount.so.1 (0x00007ff7b3992000) libc.so.6 => /lib64/libc.so.6 (0x00007ff7b37d7000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007ff7b3787000) libcryptsetup.so.12 => /usr/lib64/libcryptsetup.so.12 (0x00007ff7b3712000) /lib64/ld-linux-x86-64.so.2 (0x00007ff7b3a19000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007ff7b3709000) libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007ff7b36af000) libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007ff7b33f3000) libargon2.so.1 => /usr/lib64/libargon2.so.1 (0x00007ff7b33e9000) libjson-c.so.4 => not found libudev.so.1 => /lib64/libudev.so.1 (0x00007ff7b33b7000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff7b3396000) libm.so.6 => /lib64/libm.so.6 (0x00007ff7b3253000) libz.so.1 => /lib64/libz.so.1 (0x00007ff7b3237000) libdl.so.2 => /lib64/libdl.so.2 (0x00007ff7b3232000) librt.so.1 => /lib64/librt.so.1 (0x00007ff7b3228000) --- END --- emerge is unable to operate on this system once /bin/mount is crippled in this manner.
(In reply to Mike Gilbert from comment #1) > util-linux does not use libjson-c directly. libjson-c probably gets pulled > in by libcryptsetup. Rebuilding sys-fs/cryptsetup should resolve the issue. > > sys-fs/cryptsetup already uses a slot-operator for the dev-libs/json-c > dependency, which should trigger an automatic rebuild of the former when the > latter is upgraded. > We need to understand why this didn't happen. > As well, the preserve-libs Portage feature should prevent libjson-c.so.4 > from being removed until the rebuild occurs. > > Have you disabled FEATURES="preserve-libs"? This question should be answered. There's possibly a real bug here in that Portage should perhaps fallback if mount-sandbox fails though.