https://bugzilla.redhat.com/show_bug.cgi?id=2154347 Bill Roberts <bill.roberts@xxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|nobody@xxxxxxxxxxxxxxxxx |bill.roberts@xxxxxxx CC| |bill.roberts@xxxxxxx --- Comment #8 from Bill Roberts <bill.roberts@xxxxxxx> --- 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 -- 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=report-spam&short_desc=Report%20of%20Bug%202154347%23c8 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
