麒麟 V11 桌面系统到了预发版阶段，外设驱动、应用软件都在集中适配。我们自家的信创版本也在这轮里做了验证。

这篇记录一下我这段时间碰到的关键变化：打包方式、运行环境、以及不可变系统带来的安装与调试方式变化。

一、我们自己的适配策略：先把编译环境稳住

我们为了兼容多平台，Kylin / UOS / 中科方德，同时还要兼顾其他 Linux 发行版（比如 Ubuntu），所以走的是统一的编译与打包环境。

当前策略是：

• x86 和 ARM 统一用 Docker + Ubuntu 16 作为基础编译环境
• LoongArch 使用 Loongnix 20 的高版本环境
• 交付依然以 deb 为主，先把多架构、多发行版统一逻辑跑通

这个策略的好处是，核心逻辑只维护一套，编译和打包差异尽量被环境收敛掉。

二、包格式的变化：deb / 玲珑 / 开明

V11 开始，包管理方式是明显变化的。除了传统的 deb，还出现了开明包和玲珑包。

下面这张表是我自己的工程视角对比：

我理解的核心变化是：

• V11 默认把桌面应用放进容器化环境里运行
• 开明包是官方主推的容器化分发方式
• 玲珑包是 UOS 的路线，但在 V11 场景里必须正视它的生态影响

三、为什么我们现在还跑不通开明包

现实里并不是所有应用都能立刻迁到开明包。我们当前遇到两类硬约束：

• 应用需要加载 Host 的 SANE 设备驱动，支持扫描设备
• 授权体系依赖主机硬件特征

这两点都需要直接接触宿主环境。开明包在当前阶段很难满足。

麒麟给的官方方案是：以“特权应用”的方式，在维护层安装应用。

四、V11 的不可变系统：应用安装被“分层”了

V11 引入了磐石不可变系统，把系统拆成三层：

• 应用和生态兼容层
• 维护层
• 核心系统层

正常用户运行在“用户模式”，用户模式下 dpkg -i 已被禁止。安装到维护层需要切换到维护模式，这个流程对传统开发者来说会有点不适应。

维护模式的现实意义是：

• 可以在必要时对 /usr 做修改
• 可以安装特殊软件或做调试验证
• 维护完毕后再回到用户模式运行

这个机制不是为了折腾开发者，而是为了让系统更新与回滚更安全、更稳定。对应用开发者来说，适配路线就是拥抱这种分层。

五、一些能落地的适配结论

这一轮我更明确了几个原则：

• deb 依然是过渡期最稳定的交付方式，但必须理解“容器化运行”会改变路径与资源读取
• 开明包是方向，但不是所有应用都能一步到位
• 需要宿主能力的应用，务必评估是否需要特权模式
• 维护模式是开发调试的“必修课”，不要回避它

六、最后

麒麟 V11 在应用适配上最有价值的变化，其实不是换了个包格式，而是把“系统安全”和“生态隔离”这件事真正落到架构上。

这意味着：

• 应用开发者要接受系统的分层思路
• 传统“装包即可跑”的逻辑会被逐步替代
• 适配工作的重点从“能装上”转向“能稳住”

对我们来说，适配不仅是兼容，更是理解系统设计背后的逻辑。能跟上这套逻辑，后面的工程成本反而会更低。