首先，我对deepin系统厂商的软件的努力管理和维护，表示非常敬佩，但这种努力希望更多的是有一种标准去执行，而不是拆东墙补西墙的方式。

我在论坛的各种帖子看到，有不少文章是通过终端命令方式来补全一些软件的依赖包，甚至有些应用在使用玲珑应用管理包的方式打不开，本质还是依赖包没有进行规范到位。

具体问题，我就不再啰嗦太多，有过体验的一定知道是怎么回事。

下面，我就聊下为什么deepin现在要做应用层开发的标准，以及标准的好处。

1.用户交互端

用户交互端，是指用户在deepin系统的UI桌面中去交互的过程中，对软件或系统程序的图形化增、删、改、查，deepin系统已经对部分软件的依赖包进行了完善，但有些软件因为字体、主题等用户选择因素仍需要通过终端命令方式安装，这在现代桌面系统中是体验非常不好的。

对于字体的重新选择、新主题图片的路径更换问题，我觉得官方应该在上架软件时要求程序开发者或软件维护者提供图形化插件，以供普通用户的正常使用体验。

2.软件开发端

软件开发端，是指图形软件开发者会更多以嵌套式语法来编写用户使用软件的编码逻辑和UI布局，比如现在的QML、Arcts、flutter等等，这些前端脚本语言通过嵌套式的语法结构，能够让图形软件进行快速、稳定的产出，也便于软件开发者很好维护。

这一层面，UOS商业版仍主要依靠Qt C++来编写软件界面，以求软件的稳定性。但deepin V23版不一样，V23版桌面系统更多的是以现代桌面UI元素，不管是字体、图片、窗体，都以圆角、扁平化等元素进行改进，那么大量使用QML开发软件界面是必须要搞起来的，尽管会有性能方面的问题。

甚至，deepin- IDE后期对Qt C++的依赖也会减少，从而DTK(Qt6库版本)通过QML实现SDK化。

3.服务端或云端

服务端或云端，是指deepin系统内置程序软件需要的API接口、SDK、或云端服务层面。

比如：

实例1，嵌入式领域的电网监控公司需要无人机在山林中监控各个电线杆、电塔的工作情况，无人机飞行的路径需要调用百度地图、高德地图的第三方C/C++ API库，那么软件开发者再去查找依赖包肯定会经常重复性很多工作，deepin完全可以以百度地图、高德地图等平台为资源，进行依赖包的捆绑和维护，不要把依赖包的添加和维护交给应用软件开发者。

.......

也就是说，国内已经存在的平台，deepin生态的软件开发者要调用这些平台的SDK、API库、云端，deepin系统维护者应该首先去主动对接，而不是直接让软件开发者来提供和维护，依赖包的管理应该在这一层进行解决。

最后，deepin内部的工作者虽然搞依赖包非常辛苦，但我希望这份辛苦能够整体搞对方向，不要把依赖包问题更多交给用户主动去解决，而是在服务端把依赖包基本完善，去极大方便用户和普通软件开发者。