如何解决构建软件包时的dpkg-source源代码问题？

Question

有人在这里有过创建Debian / Ubuntu软件包的经验吗？我正在尝试将lammps软件包（http://packages.ubuntu.com/quantal/lammps）从Ubuntu 12.10（Quantal）回溯到Ubuntu 12.04。

我只需要非官方版本-只是为了方便起见，当创建自定义虚拟机映像以部署到IaaS平台时需要.deb软件包。

按照Ubuntu打包指南（https://wiki.ubuntu.com/PackagingGuide），我可以成功构建，但是当我尝试使用debuild命令重新构建时，通常会出现以下错误：

 dpkg-source: error: aborting due to unexpected upstream changes, see
 /tmp/lammps_0~20120615.gite442279-1.diff.aie32n dpkg-source: info: you
 can integrate the local changes with dpkg-source --commit
 dpkg-buildpackage: error: dpkg-source --include-binaries -i -b
 lammps-0~20120615.gite442279 gave error exit status 2

在src目录下运行'make clean-all'仍然无法解决问题。有没有办法彻底清除构建过程中生成的所有文件，或者要求debuild忽略源文件中的任何差异？

- hanxue

---

如果“我只需要非官方的 - 只是为了方便而需要一个.deb包”不适用于您：请与前面的答案保持一定的距离。请阅读下面的Stéphane Gourichon和dza的回答。 - Quasímodo

Answer 1

避免Debian的官僚主义，只需构建二进制文件：dpkg-buildpackage -b

- hendry

---

如果你打算上传到Debian，这并不是很有用。 - jeremiah

@jeremiah 但如果你要调整一个 Debian 软件包以供个人使用，这将非常有用。 - Wyatt Ward

我们中的一些人不需要上传到Debian。有时，即使我使用git archive --format=tar.gz --prefix=freeipa-4.9.8/ 4.9.8-1+devuan1> ../freeipa_4.9.8.orig.tar.gz从我的当前分支立即创建一个tarball，并且git status为空，我仍然会遇到与OP错误消息匹配的失败。这个答案让我跳过那些繁琐的步骤，确保我的应用程序仍然可以构建。 - bgStack15

Answer 2

将debian/source/format中的格式从3.0(quilt)更改为3.0(native)，如果您不想使用quilt。这对我来说解决了问题。

- xtrade

---

这个被子太难了。 - Jay _silly_evarlast_ Wren

我天真地按照这个评论的内容进行了操作。其结果是你的构建将不再使用debian/patches中的补丁。请问你能否详细解释一下如何通过修改debian/rules来实际应用这些补丁呢？ - Thomas Vander Stichele

Answer 3

这意味着您对未打包的上游源代码进行了更改，而这些更改不是debian/patches/目录中的补丁的一部分，或者如果它们是，则不在其中的series文件中列出；和/或者quilt应用补丁的状态存在一些不一致。

查看/tmp中提到的文件将显示您所说的更改。

- dobey

---

非常感谢您的快速回答！有没有一种快速恢复“make”所做更改的方法，而不是撤销/tmp/diff文件中记录的所有更改？ - hanxue

Answer 4

我在quilt错误地认为我已经对我的工作副本应用了补丁时遇到了这个问题（你可以在.pc文件夹中找到它的当前状态）。在那种情况下，解决方法是强制quilt弹出所有的补丁，使用quilt pop -a -f命令。

- Stefan van der Walt

Answer 5

@Thomas Vander Stichele

我想出了一个解决办法，它使用生成的临时文件作为补丁：

$ cp /tmp/path_to_diff_file_created_by_dpkg-source debian/patches/useful_name_of_applied_patch.patch
$ echo useful_name_of_applied_patch.patch >> debian/patches/series

https://web.archive.org/web/20150829023050/https://www.theo-andreou.org/?p=1112#toc-apply-patches-for-policy-compliance

- Theodotos Andreou

Answer 6

这可能发生在你完成了所有Debian的“手续”，但是之前的尝试中留下了一些残留物的情况下。特别是对“config.sub”、“config.guess”和“Makefile”的自动生成更改。

你可以将这个放在debian/source/options中：

# Don't store changes on autogenerated files
extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"

参考：https://raphaelhertzog.com/2011/01/28/3-ways-to-not-clutter-your-debian-source-package-with-autogenerated-files/

- Stéphane Gourichon

Answer 7

https://manpages.debian.org/jessie/debhelper/dh_clean.1.en.html

配置经常修改源代码树，您可以将这些文件列出来。

debian/clean

示例debian/clean

src/auto/config.h
src/auto/config.mk

- dza

Answer 8

这个问题通常出现在后续构建Debian软件包时，尽管您在第一次构建期间可能已经对原始源代码进行了更改。在第一次构建期间，dpkg-source会在顶级目录中创建一个<package-source>.orig.tar.{xz, gz, lzma}文件。例如，在libva的情况下，您会在顶级目录中找到它。

parent
├── libva
├── libva_2.11.0.orig.tar.xz

现在当你在libva/内进行更改或尝试构建后续版本时，它会解压这个源码tar.gz文件并尝试与新的构建文件进行比较，找到新构建中的更改。

解决方案是删除旧的源码tar文件，并使用以下命令为后续构建创建一个新的源码tar文件：

dh_make --createorig -p libva_2.11.0

并继续使用您一直在执行的命令构建 deb pkgs。通常会是：

debuild -d -uc -us

或者

dpkg-buildpackage -b -uc -us

- Sachin Mokashi

---

尽管这个答案是正确的，但它混淆了“具有破损清理策略的软件包”和“你实际上并且故意修改源文件的软件包”。对于前者的解决方案不是覆盖原始tarball，但对于后者来说，如果软件包仅供个人使用（正如发帖者所说），可能是可以的。 - Quasímodo