python3-zstandard: update to 0.22.0.

[unspecd]

Testing the changes

• I tested the changes in this PR: briefly

Local build testing

• I built this PR locally for my native architecture, (x86_64-musl)
• I built this PR locally for these architectures (if supported. mark crossbuilds):

[unspecd]

#49348 (comment)

[aryalaadi]

looks good, this fixes the ImportError: zstd C API versions mismatch; I was facing #49348

[tornaria]

Thanks @unspecd

I'm a bit unsure about the vendored zstd. Have you tried it with the system 1.5.6?

What do you think about the following patch:

--- a/c-ext/backend_c.c	2023-11-01 02:58:34.000000000 -0300
+++ b/c-ext/backend_c.c	2024-03-29 21:32:40.694372789 -0300
@@ -152,7 +152,7 @@
     PyObject *features = NULL;
     PyObject *feature = NULL;
     unsigned zstd_ver_no = ZSTD_versionNumber();
-    unsigned our_hardcoded_version = 10505;
+    unsigned our_hardcoded_version = ZSTD_VERSION_NUMBER;
     if (ZSTD_VERSION_NUMBER != our_hardcoded_version ||
         zstd_ver_no != our_hardcoded_version) {
         PyErr_Format(

This eliminates the hardcoded version; it will still check that the build-time version matches the runtime version, so if zstd is updated then python3-zstandard will need to be rebuilt (and @leahneukirchen placed a note in zstd template to that effect).

[leahneukirchen]

I'm against this PR, I don't want vendored copies of core libs. I don't mind updating the packages in sync, I just didn't know this.

…

Message ID: ***@***.***>

[tornaria]

@leahneukirchen this looks ok now, it seems it would fix #49743, and allows the update in #49348 (the commit here is identical to the second commit in #49348 except for the patch filename).

Note that python3-zstandard will still need to be rebuilt when zstd is updated, there's already a note to that effect in zstd template.