Closed jjakob closed 5 months ago
Oh, I also just relied on the libnitrokey dependency on Arch Linux. It would be great to get this straightened out, as we are also already shipping 3.8 since November 2022.
Both 3.7 and 3.8 should work fine. The hardcoded version is only used to select one of the header files bundled with pynitrokey, and there have not been any relevant changes since 3.6. Of course it would be nice to have a more flexible mechanism here, but I don’t expect any changes to the libnitrokey C API in the future, so this is not a high priority for me. I don’t see any issues with shipping this implementation with newer libnitrokey versions. Is that okay for you?
That's all that I needed. Confirmation that it's okay to depend on libnitrokey 3.8 or newer.
Definitely confirming on my side. All 3.x versions are backwards compatible regarding the API. libnitrokey 3.6 was only required here for NK Pro update support, and the headers update was done just for that.
Hi, I found a part of code that dynamically loads libnitrokey, is this hardcoded to require version 3.6.0, so we can't use a newer version like 3.8.0?
https://github.com/Nitrokey/pynitrokey/blob/c88030e050f9d567075f7731a3c69b42c0e53b45/pynitrokey/libnk.py#L93-L95
As I'm packaging pynitrokey for Gentoo, I added a dependency on libnitrokey, but didn't see this hardcoded version requirement in the code, so I previously packaged libnitrokey 3.8.0, now I see I might need to package the older version.