为什么许多GNOME应用程序包依赖于`libunity9`？
在研究这个问题时 ，我发现许多GNOME应用程序的包依赖于libunity9包。
如果我尝试在Precise上卸载libunity9 ，它会尝试卸载大量的GNOME应用程序：
MiJyn在评论中说 ，
ubuntu开发人员怎么可能认为这是一个好主意？ Ubuntu开始变得越来越像windows 🙁
libunity9包描述为：
绑定以将位置放入启动器 – 共享库
libunity是一个共享库，可以与启动器交互并在Unity环境中添加位置。
此包包含应用程序要使用的共享库
显然它是Unity的一个组成部分。 GNOME应用程序依赖Unity是奇怪的。 由于Unity是特定于Ubuntu的添加，因此上游GNOME应用程序不应该依赖它。
为什么这些依赖？
对于Shotwell和Geary（可能还有许多其他应用程序），libunity支持是运行./configure时的编译时选项集。 这样，当Ubuntu构建它时它就被启用了，但是如果他们想要的话，其他发行版可以将其关闭。
不幸的是，这意味着不使用libunity的Ubuntu衍生产品必须在没有Unity支持的情况下重建.deb，或者使用官方的Ubuntu编译包并接受它需要一个不必要的包。
请记住，libunity不是Unity。 例如，Elementary OS将libunity用于自己的自定义Dock，以在图标上显示徽章。
这与Ubuntu“越来越像Windows”有什么关系超出了我，特别是因为Windows没有包管理系统。
$ apt-cache rdepends libunity9 libunity9 Reverse Depends: libunity9:i386 libunity9:i386 libunity-dev:i386 xchat-indicator wallch unity-china-music-scope psensor liferea libunity-tools geary diodon-plugins xchat-gnome-indicator unity-webapps-service unity-scope-musicstores unity-lens-shopping unity-lens-music unity-lens-gwibber unity-lens-files unity-lens-applications thunderbird-gnome-support telepathy-indicator shotwell nautilus libunity-dev libunity-dev libbrasero-media3-1 gir1.2-unity-5.0 evolution-indicator empathy deja-dup
所有依赖libunity9的应用程序实际上都使用该库进行Unity特定集成，如启动器libunity9 ，进度条和紧急动画。 如果我没有错，那么对这个库的依赖实际上是对每个GNOME应用程序的Ubuntu特定修改，可能与上游版本无关。
Psensor的Ubuntu包装依赖于Unity来提供一些集成function：
- 直接在应用程序启动器图标中显示最高温度作为徽章
- 提供应用程序指示器中传感器值的快速访问
- 当传感器发出警报时，应用程序指示灯颜色为红色
您可以重新编译psensor并重建没有此依赖项的.deb。 这就是debian包装的情况。