spec: https://download.copr.fedorainfracloud.org/results/fed500/mbedtls3/fedora-rawhide-x86_64/05149739-mbedtls3/mbedtls3.spec srpm: https://download.copr.fedorainfracloud.org/results/fed500/mbedtls3/fedora-rawhide-x86_64/05149739-mbedtls3/mbedtls3-3.3.0-1.fc38.src.rpm Description: Mbed TLS is a light-weight open source cryptographic and SSL/TLS library written in C. Mbed TLS makes it easy for developers to include cryptographic and SSL/TLS capabilities in their (embedded) applications with as little hassle as possible. Fedora Account System Username: fed500 This package is for version 3 of mbedtls, version 2 is already packaged. They currently conflict, which needs to be resolved HTML documentation is causing some errors. May remove this.
Why are we doing this instead of upgrading the main one? Did you try to see if this is necessary?
The two versions seem to be currently maintained and updated: https://github.com/Mbed-TLS/mbedtls/releases It is unclear how many packages would break if only version 3 is available.
Ubuntu and Suse have version 2 in their repositories: https://packages.ubuntu.com/search?keywords=mbedtls&searchon=names&suite=kinetic§ion=all https://software.opensuse.org/package/mbedtls
Well, we should try in a COPR then, right? There aren't a lot of packages that link to mbedtls in Fedora: [root@94bd36f45bc2 /]# dnf repoquery --whatrequires mbedtls --qf "%{SOURCERPM}" Last metadata expiration check: 0:08:48 ago on Thu Dec 22 13:03:39 2022. dislocker-0.7.3-8.fc37.src.rpm dolphin-emu-5.0.16380-7.fc38.src.rpm freeopcua-0-36.20220717.bd13aee.fc38.src.rpm gauche-0.9.11-3.fc37.src.rpm godot-3.4.5-1.fc37.src.rpm haxe-4.2.5-3.fc37.src.rpm imhex-1.25.0-1.fc38.src.rpm julia-1.8.2-2.fc38.src.rpm lighttpd-1.4.67-1.fc38.src.rpm mbedtls-2.28.1-1.fc38.src.rpm nekovm-2.3.0-10.fc38.src.rpm openrgb-0.8-2.fc38.src.rpm retroarch-1.14.0-1.fc38.src.rpm secvarctl-0.3-4.fc37.src.rpm
Ok. Version 2.28 is an LTS and there are very many breaking changes going to version 3: https://github.com/Mbed-TLS/mbedtls/blob/development/docs/3.0-migration-guide.md
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
This is an automatic action taken by review-stats script. The ticket reviewer failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we reset the status and the assignee of this ticket.
So, We can't just update the old mbedtls package as we need to do a side-by-side transition as mbedtls 3.6 (current LTS) is NOT compatible at an API and ABI layer with the older mbedtls 2.28.x LTS versions. Another, rather unfortunate thing, is that upstream only follows semantic versioning guidelines with respect to API and break ABI at whim. Additionally, they historically miss soname updates. Ie they may break ABI, and not bump major soversion. With all of this in mind, it means they they could create a 3.7 LTS whenever, and to move to that LTS would also be an API and ABI breaking change. With all of this in mind, I propose that we create an mbedtls-3.6 package, which will provide the updates for that LTS branch. As they move to the next LTS version, we can do mbedtls-3.7. We namespace out the include directories, shared libraries, cmake snippets, docs, etc. This way older versions of mbedtls can be installed side by side with newer versions. So I am in favor of going to mbedtls-3.6 package name to give us the most flexibility with a challenging versioning scheme adopted by upstream. I am proposing the following: SRPM: https://github.com/billatarm/mbedtls3.6/releases/download/3.6.0-b0/mbedtls-3.6-3.6.0-1.fc41.src.rpm SPEC: https://github.com/billatarm/mbedtls3.6/blob/3.6.0-b0/mbedtls3.6.spec
This seems reasonable to me. Do you still want to do the review or open a new review request that would make you the main maintainer, and I can do the review?
(In reply to Benson Muite from comment #9) > This seems reasonable to me. Do you still want to do the review or open a > new review > request that would make you the main maintainer, and I can do the review? Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2282603
*** This bug has been marked as a duplicate of bug 2282603 ***