Prefer checking .so over the Python version

[utkarsh2102]

Hello @grisha,

Thanks for taking care of this project! 😄

There was a bug reported against this in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-python/+bug/1919923. However, on taking a deeper look at this, I found out the following lines of code (which I believe to be the root cause of this): https://github.com/grisha/mod_python/blob/88e444429ec2acd66eb51fa198b8dd6e1ef6a256/src/mod_python.c#L755-L758

This basically implies that as soon as there's a mismatch with the Python version number with which this module is compiled v/s what's dynamically available, it should throw the mismatch error and wouldn't work as intended. This, I am afraid, doesn't seem very distribution-friendly. For example, each time when there's a version update (either patch, minor, or major), this package/module will need to be rebuilt against that Python version, which isn't really economical. And due to this, installing this package (libapache2-mod-python) via apt and simply restarting apache2 will result in the mismatch error. This ultimately yields this library unusable.

Either we should remove this check completely or we should consider checking the .so files. For example, if there's a change in the ABI (different .so file provided v/s what's expected), (in other words, check if there's a soname mismatch and if there is,) then throw an error. Not until then, at least.

Does that make sense? I hope this is something we can change here. This would help all the downstream maintainers and distribution packagers. Let me know if you have any questions. TIA! :)

[cpaelzer]

Also it seems to be a non fatal issue, so maybe just classifying as "error" might be the problem here. As an info level log entry I guess no one would mind abut it.

What was the intention or background story for making this an "error"?

[grisha]

This code dates back to April 10, 2006 - I'm trying to understand why this hasn't been a problem over the past 15 years?

[grisha]

Also - (from looking at the code, I might be missing somehting) - but it doesn't look like it exits on this condition, all it does is just write to the error log, not any different from a 404.