问题标签 [quilt]

我是 Inkscape 的开发者之一。我们在我们的代码库中合并了一些修改过的各种免费库的块，我们真的希望以更可维护的方式处理我们的软件补丁。

我已经使用Quilt 补丁工具将补丁应用于 Debian 包中的上游代码，我们已经考虑在 Inkscape 的构建中使用它

IE，

1. 使用 Quilt 修补所有相关的上游文件
2. 编译源

这将允许我们维护上游库的原始副本和单独的补丁集，然后我们可以将其转发到上游。

我的问题是，除了 Debian 文档之外，我还没有找到任何关于如何在 Makefile 中巧妙地包含 Quilt 的示例。谁能给我指出一个这样做的项目？

我们目前使用 Automake，所以如果有一种优雅的方式可以在主构建之前运行“补丁”规则，那就太好了。

我正在尝试向 Debian 软件包添加补丁（在运行 Ubuntu 14.10“Trusty”的 amd64 机器上）。

在对问题进行故障排除时，我已将补丁缩减为添加单个文件的补丁。（为了上下文，这个文件修改了一个fluxbox包，以便它也创建一个fluxbox-dbg带有调试符号的文件。）

我按照以下步骤创建了补丁：

• （确保我已经应用了所有现有的补丁。）
• quilt new add-dbg-package.patch
• quilt add debian/rules.d/70-debug-symbols.mk
• （用我想要的内容创建了那个文件。）
• quilt refresh

补丁看起来不错：

• 应用所有补丁后，该文件存在并具有正确的内容。
• 该补丁包含一个增量，它添加了文件的完整内容，仅此而已。
• 没有其他补丁引用该文件。
• 当我弹出新补丁时，文件被删除；当我再次推动它时，它会被重新创建。

但是，当我尝试使用 重建包时debuild，我得到了这个：

如果我接受它的建议，quilt告诉我补丁是最新的（看起来是这样）。 quilt diff告诉我没有变化。

quilt正如一个想法：为 Debian 控制文件的更改添加补丁是否不正确？

谁能帮我理解我做了什么冒犯了debuild？

在我们的项目中，我们在上游软件（U-Boot）之上实现功能。每隔一两年就开始开发新硬件，并以更新版本的上游软件为基础。一些以前实现的功能几乎原样适用于新项目，无需太多修改。

因此，我们需要一个允许跟踪和重用在特定功能范围内完成的工作的工作流，而无需从整个代码库中删除它。它不应该是完美的，因为它并不经常需要，但也不应该是痛苦的。

主要问题是，有时功能会在初始实施后的几周/几个月内修复/调整，有时会重复几次，因此普通的“功能分支工作流程”将无法正常工作。

团队和代码库都相对较小（约 5 人，上游代码上分别有约 15 个 LoC）。通常一次只有一个人在处理特定的功能。

这是我们能够提出的两个选项，我将仅描述处理上述有问题的情况，因为它是唯一的并发症来源。

方法A

初始状态：功能的第一个/上一个版本在分支 X 上，几个月前最后一次更改并合并到 master

1. git checkout X; git merge --no-ff master
2. 进行更改并提交
3. git checkout master; git pull; git merge --no-ff X; git push

然后git log --first-parent --no-merges显示从一开始就在此分支上完成的提交的漂亮列表。

这种方法的主要问题是它是脆弱和限制性的：

• 如果有人在步骤 1 中使用快进进行合并，则上述检索历史记录的方法之后将不起作用。AFAIK --no-ff 可以在回购级别强制执行，但每个人都必须这样做并且不要忘记。
• 第 3 步中的 rebase-and-then-merge 也会打破历史记录，而且很多人都喜欢这种方法和 rebase。完全禁止变基可能更安全，但我不知道如何强制执行。

方法B

每次有人回去处理功能 X 时，他都会创建一个新的 X_fix_this、X_change_that 等。

缺点：丑陋和杂乱的分支列表，需要编写脚本来生成提交列表。

目前，我们在被子中保留了一组补丁。虽然这完美地解决了上述问题，但在其他方面却非常难看。

任何（更好的）想法？

我正在尝试解决 Debian 软件包中的错误，但要修复此错误，我需要更改源中文件的名称。此包使用格式 3.0（被子）。如何为更改文件名创建补丁？

目标：我想创建一个修改过的Debian源码包，即官方rrdtool包+“一些改动”。其中一项更改是添加了可执行脚本。

我有这个用于修补我使用多年的软件包的秘诀：

如果补丁不 chmod 任何文件，但使用引入可执行文件的补丁，则此方法有效，按照上面的配方会产生以下消息：

果然，当我解压我的新源包foobar时存在但不可执行。

据我了解，被子处理基于 GNU diff+patch 的补丁。GNU diff+patch 不处理文件权限。唔...

那么如何将可执行脚本引入被quilt维护的源码包中呢？

谷歌搜索没有帮助。似乎其他人已经问过了，但没有回复。

我知道我可以简单地对*.orig.tar.gz存档进行修改，但如果可能的话，我想避免这种情况。我只是惊讶于这是如此困难......

我想创建一个补丁quilt，其中有一个目录重命名。但quilt add似乎只支持文件。

如果我应该使用quilt add <old_dir>/*，那么如何将重命名的目录添加到我的被子补丁中？在创建它之前调用quilt add <new_dir>，给我一个这样的错误（这里的<new_dir>名字是_include，<old_dir>名字是include，补丁名是0001-fix-cross-compile.patch：

如果我使用没有尾随的命令/：

这不是我的意思。

如果我首先创建目录：

如何将新目录添加到我的补丁中？谢谢你。

我在 Debian 10.4 系统上。由于源代码的更改，我正在尝试编译 shadow-4.5 包。

这是我的被子程序：（来自https://wiki.debian.org/UsingQuilt）

而且，最后构建我的包：

我的包编译没有问题，但生成的 .deb 文件中包含的二进制文件不包含我的修改。

但是，当我手动编译二进制文件（使用 configure an make）时，在源代码树的 src 目录中生成的二进制文件确实包含我的更改。

除了使用 debian“debuild”推荐的工具之外，我还想通过我的修改生成 debian 包（.deb）。

我不知道是我忘记了还是做错了什么。

提前致谢

quilt与is捆绑在一起的辅助工具之一guards，它处理一个守卫列表和一个匹配守卫和文件的配置文件，并输出一个守卫规范与提供的守卫匹配的文件列表。

但是我不知道它们应该如何组合在一起：被子（1）没有显示任何调用命令来生成系列文件的方法，我没有在手册或工作副本中找到示例，并且互联网帮助不大（所有热门话题都在谈论床上用品）。

我觉得guard每当它的“依赖项”发生变化并且系列文件被覆盖时都必须手动调用，是这样吗？如果是这样，数据如何以相反的方式反馈，例如当向系列添加新补丁时，是否必须手动同步到保护文件？

背景：几年前我使用了相当多的 mq，但它本身就集成了守卫，所以来回同步根本不是问题。

我已经跑了apt-get source openjdk-8-jdk=8u275-b01-0ubuntu1~18.04。

其中收集了.dsc文件.orig.tar.gz和.diff.gz文件，然后我将其删除。这些文件旁边是一个文件夹openjdk-8-8u275-b01，其中包含一个debian/patches/文件夹。补丁文件夹内是一个列表.diff和.patch文件，但没有order文件。

我需要获取 openjdk-8-jdk 的源代码以及应用了补丁的特定版本。

运行quilt push -a返回错误No series file found.

再次运行apt-get source openjdk-8-jdk=8u275-b01-0ubuntu1~18.04会引发错误，因为该版本不再可用。但是仍然可以从https://launchpad.net/ubuntu/+source/openjdk-8/8u275-b01-0ubuntu1~18.04下载这些文件

如何获得补丁源？