Bug 723440 – sys-apps/util-linux[cryptsetup] needs rebuild after json-c update and before removal of libjson-c.so.4

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description ta2002 2020-05-16 21:46:24 UTC]

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

[Comment 1 Mike Gilbert 2020-05-17 00:58:11 UTC]

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"?

[Comment 2 lkd-gentoo 2020-05-22 11:59:17 UTC]

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

[Comment 3 Sam James 2022-07-29 08:54:31 UTC]

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