deepin 没必要进发行版仓库。
我现在就很烦，debian13的官方源里面有一些dde组件或者dde应用等，很有干扰
，应该单独一个组件仓库。
不应该进发行版主仓库里。
未来，Debian 必须提供可复现构建的软件包，因此即将到来的 Debian 14.0 将是首个遵循这一新强制要求的主要版本。自昨日开始，Debian 的软件包迁移系统将阻止无法复现的新软件包进入稳定分支，同时也将阻止那些原本可复现但后来出现倒退（regress）的现有软件包迁移。
不知是否会影响到dde
deepin 因此解决方案也很多，可以反哺回GNOME
到目前为止我没有看到任何发行版修复了GNOME构史的分数缩放实现变成Kwin 5.27+的缩放方案
在我看来就像是win7毛玻璃时代，还在用xp时代的UI
treeland上的模糊算法已经实现亚克力效果, 不是Qt无法实现只是KDE的审美问题
然后Valve默认使用KDE Plasma而非GNOME, Cannonical面向个人计算机终端的KFocus使用Kubuntu而非Ubuntu, Fedora KDE Edition升级到和WorkStation一桌的原因不必多说吧, 在正常Linux服务器运维上对于桌面的需求本来就很小, GNOME现在仍然是Ubuntu默认桌面只是因为GNOME 3时期表现优异以至于Flutter还在拿GTK3当画板的历史惯性而已
最后嵌入式设备的UI为什么要跨平台, 嵌入式设备UI实现不追求低占用去追求跨平台意义何在?
我也觉得qt还行。
KDE拿C++和qt写的，性能上比GNOME有很大优势（据说GNOME部分代码拿js写的）
审美上，qt看起来丑，但可以美化（读文档就能知道怎么美化），懒得话可以用github上的Fluent-Widget套一层
论体验，发觉qt写的软件几乎秒开，gtk还得等3~4秒（也说不定）
实用性上，qt支持Windows、MacOS、Linux甚至鸿蒙，还能与多种编程语言联动（就算只会python也能写qt软件，nuitka编译优化解君愁），gtk的主场在Linux，对Windows和MacOS开发者不友好，不支持鸿蒙
我也觉得qt还行。
KDE拿C++和qt写的，性能上比GNOME有很大优势（据说GNOME部分代码拿js写的）
审美上，qt看起来丑，但可以美化（读文档就能知道怎么美化），懒得话可以用github上的Fluent-Widget套一层
论体验，发觉qt写的软件几乎秒开，gtk还得等3~4秒（也说不定）
实用性上，qt支持Windows、MacOS、Linux甚至鸿蒙，还能与多种编程语言联动（就算只会python也能写qt软件，nuitka编译优化解君愁），gtk的主场在Linux，对Windows和MacOS开发者不友好，不支持鸿蒙
那个拿Musl Libc对着安卓ART结构一顿抄的玩意就暂时不用拿来说事了
Qt有JS, Qt5的时候就是因为QML性能不是很好导致deepin v23桌面反应在低端机上非常慢,但是Qt6开始QML的性能是被大幅加强过了
然后GTK我主要在说的4,Flutter应用用GTK3作为画板一样可以秒开,而且对于RISC-V的适配在路上
中文 
原文链接: https://security.opensuse.org/2026/04/20/winter-spotlight.html#section-deepin
审核组件是: https://github.com/linuxdeepin/dde-daemon 版本: 6.1.66, 但实际最新版本到6.1.89
总结的中文翻译: 由于安全问题反复出现，上游解决这些问题所需的时间较长，且深度操作系统项目中缺乏正式的安全修复工作流程，我们已停止为在深度操作系统中发现的问题分配CVE（Common Vulnerabilities and Exposures，通用漏洞披露）。我们认为，由于安全问题往往很快就会被其他安全问题所取代，因此进一步的CVE工作意义不大，大多只是徒增噪音。总体而言，在深度操作系统上游的安全文化得到改善之前，我们不建议使用深度操作系统的组件。
到目前为止，我们也在以较低的优先级处理深度操作系统（Deepin）的审核请求，因为多年的努力仍未取得令人满意的结果，我们更愿意将资源投入到其他更有前景的软件包中。