使用dh-virtualenv构建的Python应用Debian包在Raspbian Bullseye上无法运行

• dh-virtualenv构建产物绑定构建环境的Python版本：在Raspbian Buster（默认Python3.7）环境下构建的deb包，内置虚拟环境完全基于Python3.7生成，所有CPython扩展包的.so二进制文件均针对Python3.7的ABI编译，和Bullseye的Python3.9 ABI完全不兼容，无法被Python3.9加载。
• 虚拟环境配置失效：构建产物中的pyvenv.cfg配置文件指定的基础解释器路径为Buster系统的/usr/bin/python3.7，该路径在Bullseye系统中不存在，导致虚拟环境启动时无法正确初始化，因此不会自动将虚拟环境的site-packages路径加入sys.path。
• 扩展模块命名规则不兼容：Python3.8及以上版本修改了CPython扩展模块的默认命名规则，新增了Python版本号、架构标识等后缀，Python3.7版本生成的.so文件不符合3.9的命名匹配规则，就算手动追加了sys.path，Python3.9也无法识别对应扩展，虚拟环境内的pip运行时会自动适配当前系统的Python3.9的扫描规则，因此也无法识别到3.7版本的扩展包。

• 方案1（推荐）：在Raspbian Bullseye环境下重新构建deb包
  • 升级构建服务器的系统版本到Bullseye，安装适配Bullseye的dh-virtualenv版本，构建时直接使用系统默认的Python3.9作为虚拟环境的基础解释器
  • 重新拉取所有依赖打包，新构建的deb包内置的虚拟环境完全适配Python3.9，sys.path加载和CPython扩展识别的问题都会自动解决
• 方案2（单包兼容双系统场景）：修改构建规则适配多版本
  • 修改dh-virtualenv的构建配置，不要硬编码Python解释器版本为3.7，指定为通用的python3
  • 在deb的postinst安装脚本中添加逻辑，安装时自动检测当前系统的Python版本，动态将对应版本的site-packages路径写入应用启动脚本的PYTHONPATH环境变量
  • 构建时预编译Python3.7和3.9两个版本的CPython扩展，按版本区分命名后一同打包到虚拟环境的site-packages目录
• 方案3（临时调试用）：现有安装包快速修复
  • 安装deb包后，手动删除虚拟环境中旧的CPython扩展文件，执行path/to/virtualenv/bin/pip3 install --force-reinstall [缺失的扩展包名]，强制重新编译安装适配Python3.9的扩展版本
  • 修改应用的启动脚本，在启动前先导出虚拟环境site-packages的路径到PYTHONPATH变量

内容的提问来源于stack exchange，提问作者M1ghtyN4te