Bug 805011 (mbedtls-3) – [TRACKER] >=net-libs/mbedtls-3.0 breaks multiple revdeps

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Joonas Niilola 2021-07-29 10:37:06 UTC]

Upstream has provided migration instructions from 2. to 3. to its downstreams, 
  https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0

so it's clear the revdeps of mbedtls need to be updated in Gentoo before =>3 can work.

https://qa-reports.gentoo.org/output/genrdeps/dindex/net-libs/mbedtls

[Comment 1 Larry the Git Cow 2021-07-29 10:46:14 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=33cd33cd8fccba7b9c4cdffdfc0b1b23226a2c7b

commit 33cd33cd8fccba7b9c4cdffdfc0b1b23226a2c7b
Author:     Joonas Niilola <[e-mail]>
AuthorDate: 2021-07-29 10:39:12 +0000
Commit:     Joonas Niilola <[e-mail]>
CommitDate: 2021-07-29 10:46:05 +0000

    profiles: mask >=net-libs/mbedtls
    
    Bug: https://bugs.gentoo.org/805011
    Signed-off-by: Joonas Niilola <[e-mail]>

 profiles/package.mask | 5 +++++
 1 file changed, 5 insertions(+)

[Comment 2 Joonas Niilola 2021-07-29 10:48:42 UTC]

Here's a suggestion: re-introduce mbedtls-3.0.0-r1 with a SLOT="3/16" defined, revbump all rdeps to (R)DEPEND on :0 until a patched ebuild version is introduced to depend on :3.

[Comment 3 Anthony Basile 2021-07-29 17:05:18 UTC]

(In reply to Joonas Niilola from comment #2)
> Here's a suggestion: re-introduce mbedtls-3.0.0-r1 with a SLOT="3/16"
> defined, revbump all rdeps to (R)DEPEND on :0 until a patched ebuild version
> is introduced to depend on :3.

I would rather do SLOT="3/10.16.4"  Comments before I rev bump?

(Its masked for now so we should be safe to play around a bit.)

[Comment 4 Joonas Niilola 2021-07-29 17:22:08 UTC]

There's some ongoing discussion happening in the linked pull request:
https://github.com/gentoo/gentoo/pull/21820

I think the strongest suggestion now is to keep this masked, discover all broken rdeps, and add fixed rdeps one-by-one with their addition to package.mask. But please participate in the PR discussion, nothing's been decided yet.

[Comment 5 Azamat H. Hackimov 2024-02-08 23:20:03 UTC]

As a new maintainer I'm thinking of splitting the package to mbedtls:2 and mbedtls:3 in order to keep both versions in the tree. Some packages are unable or not willing to migrate to slowly deprecating mbedtls:2 branches, so we are forced to keep them both for a while.

There two approaches to implement subslotting:

1. Placing installation into /usr/lib/mbedtls2/ with symlinks in /usr/lib/ (so we don't need to mess with LD_LIBRARY_PATH; Arch Linux chosen this way, see https://gitlab.archlinux.org/archlinux/packaging/packages/mbedtls2/-/blob/main/PKGBUILD?ref_type=heads).
2. Renaming libraries itself to libmbedtls{2,3}.so libmbedcrypto{2,3}.so and libmbedx509{2,3}.so with soversion symlinks (i.e. libmbedtls.so.2.18.7).

Both approaches require adjusting their building in the configuration process. While option 1 is easy to implement, I think to go option 2 because MbedTLS 3 already has cmake config files for dependency discovery, and option 2 more fits for this. As for MbedTLS 2 I'm planning to backport that config generation.

Upstream has some issues in build system that I intend to fix with these PRs in order to achieve subslotting features (https://github.com/Mbed-TLS/mbedtls/pull/8800 and https://github.com/Mbed-TLS/mbedtls/pull/8795).