系统：Kubuntu 20.04 LTS
长话短说，我做了以下事情：
apt remove --purge kdevelop
find /usr/ -type f -name "*kdev*.so*"
rm -rf /usr/lib/x86_64-linux-gnu/libblockdev.so.2.0.0
apt remove --purge kwrite
find /usr/ -type f -name "*kwrite*.so*"
rm -rf /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/kwrited.so
apt autoremove
apt install kwrite
apt install kdevelop
现在有些东西不再起作用了；有些程序需要 5 分钟才能启动，有些则根本无法启动。
这些文件未安装，我认为这就是问题所在。
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/kwrited.so
/usr/lib/x86_64-linux-gnu/libblockdev.so.2.0.0
一个可能的解决方案是重新安装 KDE Plasma 桌面，但我不想丢失我的设置（颜色、图标、动画、功能......），我已经为此工作了一个月，但仍然没有完成。
我该如何解决这个问题而不丢失桌面设置？
如果你想知道我为什么这样做，这里是完整版本：我遗漏了一个功能凯特和韩国开发公司，用于在侧边栏打开文件夹的加号。Ubuntu使用 Kate 的 19... 版本，但已经有 21... 版本可用，并且在 21 版本中存在加号。没有 Kate 的 repo，只有 Ubuntu reopsetory，所以我不得不下载 appimage。启动 Kate 应用程序映像后，单击文件夹时我必须等待大约 30 秒才能打开。我认为这是因为安装了 Kate V.19...，并使用 apt remove --purge kate 卸载了 Kate V.19。但什么都没有改变。然后我想起 Kdevelop 也已安装并且它也可以与 Kate 一起使用，所以我也卸载了 KDevelop（apt remove --purge kdevelop）。但这也无济于事，所以我用 apt autoremove 清理了系统并搜索 Kate 文件并将其删除。系统重启后它启动了。KDE Plasma 桌面需要5分钟才能启动。Dolphin 文件探索器需要 5 分钟才能启动并且无法访问其他分区和驱动器。GNOME 磁盘实用程序根本无法启动等等。
答案1
解决此问题的方法是恢复手动删除的系统文件
/usr/lib/x86_64-linux-gnu/libblockdev.so.2.0.0
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/kwrited.so
使用Ubuntu 软件包搜索找出被删除的文件属于的软件包libblockdev2和kwrited。
只需重新安装这些软件包：
sudo apt install --reinstall kwrited libblockdev2
答案2
请允许我回答您的隐含问题 - 与存储库中的软件相比，如何获取较新版本的软件以及在此过程中需要注意什么。在您的具体情况下，您想要更新的是 Kate，但一般来说，这适用于任何软件。
来自“多平台包管理器”的所有应用程序（尼克斯，扁平包装，应用程序图像，折断，自制- 无论如何）注定要启动时间更长、响应速度更慢、占用更多 RAM 和磁盘空间。你无法欺骗物理定律。
发生这种情况的原因是此类应用程序不依赖于您已安装到系统中的共享库。您现有的一组共享库是由其他应用程序带来的，并且很可能这些库已被您在会话中运行的其他应用程序加载到 RAM 中。
appimage-ish 应用程序所做的是安装它们所需的任何库/依赖项，然后在启动此类应用程序时将它们加载到内存中. 成本是使用额外的 RAM 和 CPU 时间用于加载所有这些依赖项，它们仅由单个 appimage 应用程序使用。
如果您在具有快速 CPU、大量 RAM 和 SSD 而不是 HDD 的优质硬件上运行操作系统，您可能甚至不会注意到这种性能下降，但如果不是这种情况，您会用肉眼看到差异。
我看到一些 youtuber 炫耀一些浏览器在综合测试中性能下降仅仅 5-10%，但他忘了提到他的硬件也只下降了 5-10%，这已经相当不错了。在你的特定硬件上，数字会完全不同。所以不要被骗，不要被愚弄。
当然，你选择的特定 appimage 版本可能有错误，并且会无缘无故地消耗 CPU 周期或浪费内存。一个正确的解决方案是“分析”应用程序，以查看时间花在何处，并错误报告把这些都交给开发人员，这样他们就可以修复问题。但这需要很多复杂的技能和时间。
更实际的解决方案是尝试该应用程序的 N-1 或 N+1 appimage 版本，或者从不同的 repo（如 flatpack 或 nix）中尝试。
当然还有最后一个选项。就是下载您想要的应用程序的最新版本的源代码（假设它在您的 Linux 发行版的 repo 中缺失）并尝试自己编译它。大多数用户会发现，他们尝试编译的应用程序的较新版本依赖于他们无法从 repo 中获取的某些库的较新版本 - 因此他们也需要编译它。该库可能需要另一个库，另一个库......大多数人会放弃自己编译它的尝试 :) 但您仍然可以尝试一下。如果成功，该应用程序将具有您想要的所有最新功能，并将尽可能多地使用您现有的共享库。Archlinux 用户将很乐意与“AUR”分享他们的经验。或者 Gentoo 用户与“emerge”分享。
抱歉，写了这么长，但我希望这能澄清一些事情。