https://bugzilla.redhat.com/show_bug.cgi?id=2154347
Bill Roberts <bill.roberts(a)arm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|nobody(a)fedoraproject.org |bill.roberts(a)arm.com
CC| |bill.roberts(a)arm.com
--- Comment #8 from Bill Roberts <bill.roberts(a)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/mbedtl...
SPEC:
https://github.com/billatarm/mbedtls3.6/blob/3.6.0-b0/mbedtls3.6.spec
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2154347
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...