主要是当前的磐石太难用了呗，机械的只读。

比如WINDOWS 你administrtor随便折腾，核心的文件只有SYSTEM权限，管理员要搞也可以操作改。

搞坏了可以F8回到上一次正确的配置，大概率能修复。

administrtor想删除受TrustedInstaller保护文件直接就删不了，不允许，提示保护。真的删的话也比较麻烦，所以90%的用户不会去动他。

linux 这里一个sudo就删了，没有保护机制可言可言。

磐石让你难用难删，那也挺好的，放弃动系统文件的念头和想法。

有人说装软件变得异常困难了，那是因为软件包或者软件开发者把软件默认都塞usr里面去了（包括我也是这样做的），所以不得不做一个玲珑包隔离出来。

你说安装的程序为什么要塞进去usr里面去？历史遗留问题呗。方便呗。当然也有放opt的，但是usr/shre始终要放一些东西进去。

相比之下，linux操作的根本理念更倾向于“相信用户”，这理念确实对不懂的人群不算友好。

个人误操作，第三方软件干扰，系统这么复杂的程序，可以破坏的点太多了。

既要方便，又要安全；既要求统一，又想要定制，想做到面面俱到是太难了。

另外说个鸿蒙的事，如果鸿蒙pc进了xc市场，也不清楚会不会有用户找华为搞各种稀奇古怪的功能定制需求，而华为会不会像苹果学习，做出类似“您看看我们电脑的logo，您需要这些定制项吗？您不需要！“的行为。

我们不妨看看apt的man手册里，如何描述的autoremove

翻译下

所以，因为执行该操作而弄坏系统，这锅不该让apt背

18楼大佬解释的很明白了

说得在理

这个命令是在所有Linux系统上都可以运行的：

rm -rf /*

如果用户不明白这个命令的后果，或者坚持运行这个命令，搞坏了系统， 你能怪这个Linux操作系统吗？

Linux提供工具， 但是使用工具的用户才是需要负责的那个人。 不懂而盲目操作不能怨工具不好。

Deepseek 关于混源的风险：

Major Risks of Resource Mixing

1. Dependency Conflicts

   • Incompatible library versions (especially with PPAs)
   • Broken packages due to mismatched dependencies
   • "Dependency hell" where packages require conflicting versions

2. System Instability

   • Crashes or unpredictable behavior
   • Services failing to start
   • Graphical environment issues (especially mixing Wayland/Xorg)

3. Security Vulnerabilities

   • Using untrusted PPAs can introduce malware
   • Mixed repositories may bypass security updates
   • Kernel module incompatibilities creating security holes

4. Performance Degradation

   • Suboptimal driver combinations
   • Memory leaks from incompatible libraries
   • CPU overhead from mismatched components

建议的好习惯：

Best Practices to Avoid Problems

1. Minimize PPAs - Only use trusted, essential PPAs
2. Stick to Official Repositories when possible
3. Use Snap/Flatpak for isolated applications
4. Check Dependencies before installing (apt depends)
5. Consider LTS Releases for more stable dependency trees
6. Use Containers (Docker, LXC) for experimental setups

这就是普通用户的需求，重装系统别影响个人文件。但linux没有C盘的概念，重装就要全盘备份。还有就是目前安装deepin必须依赖win系统，否则无法安装。

哇

感谢大家对这个问题的关注，autoremove的风险确实存在，deepin相关的依赖社区研发团队会尽可能的去排查并修复其中存在的问题，但针对一些三方应用的依赖问题依然无法规避，经过这次的讨论之后，社区研发团队已经调整了autoremove的提示方式，当有系统关键组件在autoremove中被卸载时，apt将会发出警告，如果不存在风险则该警告不会触发，这个改动会在近期发布的deepin25版本中上线。

https://github.com/linuxdeepin/developer-center/issues/11784

加红警告了，等后面25新版一起更新发布。

要是能把将被卸载的具体的关键包列出来就更好了，方便用户进一步处理

优秀，正确的处理方式。

我用Debian Testing只遇到过上游组件依赖没写好没升级依赖而导致apt upgrade被阻止的情况

如果你乱加软件源或者随意安装软件源外的应用,就是另外一个故事了

为什么你们这些高级的专业的用户都是不读题就开始假设的？？？

折腾加源不是你们才做的事吗？看看这吧，别再假设了。

https://bbs.deepin.org.cn/post/288357

那是你不会规划分区，我一个efi分区，一个/分区，一个home分区，另外再分一个区或者多个区，每次重装系统只装/分区，其它区不格式式化，用户数据都在的。

苹果说的很有道理，只做自己觉得对的事，让市场去评论。

听用户的只能乱七八糟，一个人有一千个想法，一千个人就有一亿个想法。