我正在从 pacman 安装 SFML，它需要 freetype，并且我在 freetype 和 harfbuzz 之间遇到了令人讨厌的循环依赖，这是另一个问题。
我的主要问题是关于这个依赖链：
Freetype -> harfbuzz -> glib2 -> python -> sqlite 等
$ pactree -s mingw-w64-x86_64-sfml输出一棵非常大的树。我认为freetype是一个轻量级的库......
我想要 sfml，最后得到了 python 和 sqlite，安装了 350MB。
这正常吗？
我并不真正了解所有 harfbuzz 或 glib 是如何编写的，但这些依赖项似乎超出了范围。
FreeType 使用 HarfBuzz 作为“改进的 OpenType 字体自动提示”的整形器。这对于基本的 FreeType 操作并不是严格要求的，但是否使用它是编译时的选择。
HarfBuzz 并没有太多使用 GLib 公共运行时，但它似乎导入了 GLib 提供的 Unicode 规范化函数。
（另外，额外的 CLI 工具（例如“hb-view”或“hb-shape”）也是使用 GLib 提供的函数编写的，用于字符串操作、UTF-8 解码等。这些工具不是基本操作所必需的，但每个发行版都决定是将它们包含在主包中还是拆分为“-bin”包。）
GLib 包括用 Python 编写的开发人员工具，例如“gdbus-codegen”或“glib-mkenums”。这些对于基本操作不是必需的，但每个发行版都决定是否将 Python 设为可选的 dep，或者将开发人员工具拆分为“-dev”包，或者以惰性方式进行。
总的来说，这三个库本身是非常合理的依赖关系（也就是说，减去 6 年未解决的依赖周期并且还在继续），但是强制 GLib 包依赖 Python 是您的发行版的错。