作者在重新评估 TensorFlow 的最近版本的状态之后，写了本文分享他关于深度学习框架打包的一些观点。作者的想法是从失败而不是成功中总结出来的，也就是说，作者总结的这些观点应该对将来想要维护类似包[1]的维护者有所帮助。

在 Debian 的环境中，维护者必须面对这三个障碍：

许可证。不幸的是，事实上占主导地位的性能库是 cuDNN[3]。我想说，没有一个真正的用户 [4] 会去使用不带 cuDNN 或 TPU[5] 加速的深度学习框架。在 Debian 中，维持一堆贡献软件（contrib）或非自由软件并不是什么好经验。在 Salsa:nvidia-team 使用 cuDNN 打包是可行的，但是上传计划已经流产，因为它的许可证看起来太可怕了。
ISA 基线。如果你还记得 SIMDebian[6]，或者我使用 DUPR[2] 的一些动机，那么你就会很容易理解 SIMD 代码的缺失将会如何影响关键的计算性能。人们在这方面提供了一些有用的建议，包括 ld.so 技巧和一些 gcc 特性，这些特性允许根据 CPU 能力 [8] 选择运行时代码。ld.so[7] 技巧会使得到的.deb 包膨胀，但它却是最适用的解决方案。相比之下，修补一百万行 TensorFlow 代码来启用“函数属性”特性对志愿者来说有点是天方夜谭的事。
构建系统。看看 TensorFlow 和 PyTorch[10] 的构建系统。由于发展速度过快，它们很不稳定。具体而言，TensorFlow 的构建系统“bazel”对 Debian 来说，打包很难，而且仍然需要大量的修补工作来阻止构建 TensorFlow 之前，bazel 需要下载大约 3GB 不知干嘛用的数据[9]。PyTorch 的构建系统 “setup.py+cmake+shell”……也需要一些修补工作。

因此，我建议任何准备处理任何深度学习包的贡献者要仔细评估我上面提到的这三个方面。在一定程度上，我很羡慕其他发行版，如 Arch 和 Gentoo，因为它们在这一领域取得了很大的进步。

那时候（也许就几个月前？），在 Debian 科学团队中，我说要终止深度学习框架相关的开发。之后 Paul Liu 找我询问了关于 src:tensorflow（实验中）的状态。我花了几个小时重新评估形势，最后决定完全放弃，并写下了本文上述几个观点。因为我不愿意再承担任何工作量了。与此同时，我针对 tensorflow 和它的几个依赖项提交了 Orphan[11] 的 bug，但 src:nsync 除外，它包含一组简洁的 cmake 文件。我计划一年后把这些 Orphan bug 转换成 RM bug，如果没有人去碰它们的话。

我使用神经网络进行研究，并经常使用这些框架。Anadonda 和 Pip 对我来说已经足够好了，所以如果我想要一些.deb 包的话，DUPR[2] 对我来说是最好的选择。

这一次，我真的放弃了所有相关的努力 [12]，永远也不会再次触碰它们了。对此，我并不会感到遗憾，即使这些观点与我的一些 Debian 活动紧密相关。

这个结果确实看起来听糟糕的，但我们相信，太阳每一天都是新的。

[1] 请特别注意计算性能。

[2] https://github.com/dupr/duprkit

[3] （非自由软件） https://developer.nvidia.com/cudnn

[4] 商业团队，研究人员。

[5] Google 的计算加速硬件

[6] https://github.com/SIMDebian/SIMDebian

[7] man ld.so ->搜索“硬件能力”（hardware capabilities）。

[8] info gcc“函数属性”（Function Attributes）：见 Guillem 的最近回复“SIMDebian：……”（d-devel@l.d.o）

[9] 我不清楚它们是什么，它们不仅仅是构建版本。

[10] 它们是最重要的两个框架。

[11] 终于解脱了。

[12] 不包含我正进行的关于 intel-mkl/BLAS/LAPACK 的工作。我仍然对 Debian 开发的许多其他方面有着浓厚的兴趣。

创作场景

Debian 环境中，深度学习框架打包有哪些难点？