付老师，你好：
非常感谢你的建议，检测出哪些二进制不能兼容的情况下，有一个”中间层”，实现在OS 升级的情况下，对已有软件的兼容，是一个非常有创造力的想法，实际目前受开源组件版本升级的影响，惯用的做法是在某个OS版本编译出来的业务软件就在对应的版本OS上安装使用，避免版本不配套带来的兼容性问题。
为了支撑更好的做搬迁，减少操作系统升级对业务软件带来的影响，目前社区也在探索一些方法，比如说多版本引入、容器化，这些都可以作为 迁移主线的一个补充，前期SIG组也做过一些分享及探讨，目前这方面正在进行中。
对于操作系统的组件，有中间件、运行库、加速库等分层，这个“中间层“是否存在、在哪层定义比较合适，每层实现有哪些约束及挑战，运行框架如何保障加载配套的版本，欢迎下次兼容性SIG会议上在“中间层”的方向上做一些探讨。
谢谢！ openEuler 杜开田
发件人: fugz1@chinatelecom.cn fugz1@chinatelecom.cn 发送时间: 2023年2月24日 10:48 收件人: oecompatibility oecompatibility@openeuler.org 主题: [Oecompatibility] openeuler社区兼容性问题讨论
大家好：
我是天翼云基础架构，系统软件的研发同事。我们使用openeuler社区版本20.03 sp1版本自研了ctyunos2系统。 当前也在做使用x2工具做搬迁适配工作，以及发布基于22。03 sp1的ctyunos3版本. 这多方面的工作交叉过程中，我们思考了一个问题，就是怎样能基于x2工具，开发实现一个类似20.03->-22.03的无感知升级。 这里的痛点是我资源池现网的环境上，已经大批量使用2003的版本，所有的业务软件都是基于此版本编译发布。 对于电信这种大体量的业务适配和替换周期会很长（2/3年），所以希望能把现网系统直接替换成22.03后，原来的2003上的业务二进制保留。 无感知正常运行，在中间做一层隔离层，其实就是当前x2工具可以检测出哪些二进制不能兼容保留的情况下，针对这些不兼容软件，做一个框架，实现能保留下来。 给客户多一个选择，是保留还是适配新的系统版本。完善，扩展x2的上游能力。
________________________________ 付广哲 天翼云科技有限公司 基础架构事业部 电话：15311615356 地址：北京市海淀区 庚坊大厦5层