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
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 <juippis@gentoo.org> AuthorDate: 2021-07-29 10:39:12 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-07-29 10:46:05 +0000 profiles: mask >=net-libs/mbedtls Bug: https://bugs.gentoo.org/805011 Signed-off-by: Joonas Niilola <juippis@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
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.
(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.)
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.
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).