xpt*_*xpt 0 debian module package go
要理解这个 Go 问题，需要先了解一下 Debian 打包 Go 模块的要点。基本上，Go 模块 Debian 软件包的设计是只能由 Debian 软件包本身使用，而不能用于我们日常的 Go import。
然而，因为它们只是我的操作系统文件系统中的文件，所以我们肯定有办法在日常 Go 中使用 Debian 软件包import。以前有人成功做到过吗？
我问的原因是，有很多 github 存储库包含巨大的模块，但我想要的只是其中的一小部分，而该部分恰好已经打包为 Debian 软件包。也就是说，使用go get将为我提供大量我不需要的代码库，同时apt get可以为我提供我需要的东西，如果我可以利用它的话。
AFAIK，您需要附加 /usr/share/gocode到您的GOPATH环境变量（在您自己的私有 Go 工作区之后，用 分隔:）以使这些包可用于go工具链。
请参阅本指南（并查看dpkg -L任何已安装的感兴趣的 Go 库包 \xe2\x80\x94 的输出，您会看到该包的导入路径实际上位于 下/usr/share/gocode/src）。
（扩展 @Flimzy 在对原始帖子的评论中建议的内容，@JimB 在他们的 \xe2\x80\xa6 中扩展）
\n\n您可能需要清楚地说明您在开发时的意图是什么。
\n\n“问题”在于 Debian 和 Go 管理依赖关系的方法存在一定的不一致：
\n\nGo 社区建议的常见做法是修复依赖项的特定版本（现在通过go 模块\xe2\x80\x94 ）并让工具链为您获取并安装它们，或者供应商您的依赖项 \xe2\x80\ x94 在逻辑上是相同的，但在这种情况下，您实际上将这些依赖项作为代码库的一部分（它们只是位于特定目录中）。
\n\n前者建议用于库代码和通常可供第三方重用的代码，而后者通常由“最终”产品（通常是内部开发的）使用。
Debian 采取的方法是集成：可以理解的是，他们拒绝不受控制地嵌入依赖项的想法，并尝试确保与其他任何东西“反向依赖”的所有内容都正确打包，并且理想情况下只有给定的单个版本库存在于任何特定的操作系统版本中（但这在现实生活中并不总是可能的）。
这两种方法最终都不是“正确的”，因为它们迎合了不同的用例。
\n\n需要考虑的一个重要事情是，大多数（如果不是全部）用 Go 编写行业代码的团队都将底层操作系统视为无聊的实现细节 \xe2\x80\x94 ，就像一团不太有趣的“东西”一样只需要运行目标产品（如今，通过使用容器将这种方法发挥到极致）并自行管理其依赖项。
\n这是为什么呢？
\n这是一个哲学问题。我认为这主要归结为企业中普遍缺乏具有适当技能的人员来与目标平台进行适当的集成，同时 \xe2\x80\x94 维护您自己的经过尝试和测试的依赖项版本的容易性，而不是发行版提供的那些。
现在让我们从另一个角度看一下 Debian 打包的 Go 库。
\nDebian 打包者通过包装 Go 库包来解决以集成为中心的任务，这种方式使它们可供 Debian 的构建助手使用（请参阅 参考资料dh-golang）。也就是说，在 Debian 中，当您准备用 Go 编写的某些程序的包时，您将不可避免地使用该dh-golang东西来确保以可以使用已安装的包的方式调用 Go 工具链。
现在考虑一下相当大比例的 Go 库代码，并且许多可运行的程序与平台无关，如果您编写的 Go 代码旨在通用，因此将在某个地方发布（例如在一些流行的 Git 上）托管解决方案），最好以任何开发人员都可以轻松获取并能够在没有任何特殊准备的情况下使用它的方式组织代码。
\n\n所以，我要引导你的是，除非你正在编写肯定只在Debian 中使用的代码，否则你的方法可能是正确的，但如果你正在编写“常规”Go 代码，我\建议将“编写+维护代码”和“Debian 集成”任务分开 \xe2\x80\x94 也就是说，按照 Go 社区推荐的方式编写代码，然后编写使用已安装依赖项的 Debian 包。
\n请注意，对于后者，您可能首先需要实际打包所有缺少的依赖项。