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