使用git-buildpackage时，获取上游源有两种方式：
我的团队正在研究打包 Oracle Java。我们在 git 中开发我们的包并希望使用 gbp。显然，选项（1）是不可能的，因为来源不可用。但是选项（2）也不可行，因为这意味着将巨大的（200MB+）档案导入 git。
由于 Debian 的政策是针对专有软件的，因此您在此找不到太多关于此用例的文档。不过还是有办法的。
dpkg-buildpackage 也不够，因为get-orig-sources is deprecated。现在您应该使用 uscan 和 debian/watch 或 git-buildpackage。
【问题讨论】：
--uscan option。它将它导入到存储库中，因此它与其他选项一样不合适，但可能对自动构建包很有用。
git buildpackage 和大文件没有问题。是什么让你觉得有？
将“巨大”的 tarball 导入 git 存储库时，您预计会出现哪些问题？
它们与gbp 有关吗？或者它只是git 处理大型二进制 blob 的方式（这实际上是完全不同的事情）。
如果您真的担心大型存储库大小，您可能需要查看 git-lfs 或类似的。
哪个用例？ 拥有庞大的发行版 tarball 并不是专有软件所独有的。 （想想游戏……有 FLOSS 游戏带有数以万计的数据）。
所以你的选择是：
- 要么包括大型上游 tarball
- 或者重新打包它们以丢弃您不需要的东西（例如，用于 W32、W64 和 BeOS 的预编译二进制文件在 Debian 包的上下文中通常是无用的，但会极大地扩大包装尺寸）。获取上游 tarball 的标准工具 (uscan) 包括在导入新的上游版本时自动删除文件的机制。
那又怎样？您引用的文章明确指出它“存在于 debian/rules 文件中绝对没问题”。
此外，git-orig-source 与 uscan 的问题与您所描述的问题正交。
两者都是从远程位置获取源代码以开始打包新版本的方法。
也没有在构建过程中用于获取其他缺失的上游源（您可能会感到困惑，因为get-orig-source 是一个 Makefile 目标。但这个目标实际上从未被调用，除非手动调用由想要获取源代码的人提供）。
为什么不呢？ 如果你在 dpkg-buildpackage 可以找到的地方有 orig-tarball，你当然可以使用它。
gbp 是一个非常好的集成工作流工具，可将 Debian 打包（/debian 中的所有内容）和上游快照保存在单个存储库中。
这可能不一定是您想要的工作流程（例如，因为您明确不希望在打包存储库中包含上游源）。
在这种情况下，gbp 可能不适合您。
幸运的是，绝对没有什么会迫使您使用此工具。随意使用git-dpm、dpkg-buildpackage，或者在没有任何帮助的情况下手动滚动你自己的包。
【讨论】：