https://bugzilla.redhat.com/show_bug.cgi?id=2154347
Bill Roberts bill.roberts@arm.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|nobody@fedoraproject.org |bill.roberts@arm.com CC| |bill.roberts@arm.com
--- Comment #8 from Bill Roberts bill.roberts@arm.com --- 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... SPEC: https://github.com/billatarm/mbedtls3.6/blob/3.6.0-b0/mbedtls3.6.spec