我认为 Ubuntu 尊重“修改软件的自由”，但如何在不破坏系统的情况下修改 Ubuntu 软件包的源代码？破坏系统是指例如创建无法解析的依赖关系或阻止将来的apt update更新，尤其是安全更新。
有没有办法保存修改的“补丁”并将其应用于将来的任何 apt 更新？我宁愿完全避免“分叉”软件包。
这是“apt pinning”的用途吗？还是 Ubuntu 的“稳定性模型”（我不确定这是否是正确的术语）不支持用户修改？如果其他发行版对此有不同的处理方式（Arch/Gentoo），我将不胜感激。
答案1
其工作原理一般是，发行版的软件包维护者从官方来源（GitHub、SourceForge 等）获取原始源代码；上游代码）通常以 tarball（压缩的 tar 存档）的形式提供。这些代码将保持原样；原始的正如它的名字一样。
但通常需要进行一些调整，以便所有内容与整个发行版配合良好。因此，软件包维护者将这些原始源代码解压到工作目录中，并根据需要更改源代码；然后使用命令diff生成更改集，即原始版本和现在修改（“修补”）版本之间真正更改的几个地方。
此变更集称为差异或修补。对于每个包，可以有一个或多个；通常它们按主题组织；即一个用于目标分布上的不同路径，另一个用于解决此软件调用的另一个程序的怪癖等；你明白了。
然后，原始 tarball 和 diffs/patch 被放入另一个存档（a源码包)，但保持足够的分离，以便一切都保持透明。
当包裹现在建造，这意味着首先解压原始 tarball，然后应用第一个补丁（使用该patch程序），然后应用第二个补丁等等；当修补阶段完成后，编译过程才真正开始（调用make和make install以及其他必要的操作）。
据我所知，所有 Linux 发行版都是这样做的；Ubuntu、Debian、SUSE、Red Hat，随便你怎么说。可能所有发行版都一样，BSD 变体可能也一样。
因此，源码包；这就是你要做的。没有什么可以阻止你拿一个源包并在其上添加另外一两个补丁；并在此基础上生成你自己的源包。
需要注意的是，现在您必须自己重建软件包；并确保在新版本发布时（即每次软件包更新时）将补丁添加到源包的新版本中。
那能可以完成，但很乏味。很有可能你一直没有动力去做这件事；这取决于包的实际变化频率。
缓解疼痛的一个工具是openSUSE 构建系统（OBS）支持至少部分自动化。但您仍然需要重新导入源包并添加自己的补丁。它可在网上免费获取，并且可以为各种发行版构建软件包，不仅包括 openSUSE，还包括 Ubuntu、Debian 和其他发行版。
因此，如果您的更改引起了普遍关注，您可能需要联系发行版的软件包维护者，如果他们不想将您的更改包含在其源包中。或者，如果他们不想向所有人发布你的更改。
如果这是针对您的用例非常具体的事情，那么显然行不通。在这种情况下，请考虑不同的策略。