背景
Debian 已经决定开始进行 合并 /usr 过渡，这意味着 /bin 将成为 /usr/bin 的符号链接，/lib 将成为 /usr/lib 的符号链接，等等。支持者声称，这将与其他 Liunx 分发的文件系统布局相同，并消除了一些不再特别有用的复杂性（例如，必须决定什么应该在 /bin 中，什么应该在 /usr/bin 中）。
2021 年 2 月，Debian 技术委员会（DTC）决定，从 Debian bookworm （Debian 12）开始，Debian 只支持合并 /usr 文件系统布局的系统。
然而，在 Debian Salsa 上的一个讨论表明，合并 /usr 过渡仍然存在未解决的问题。
问题
Russ Allbery 指出，合并 /usr 过渡迄今为止并未完成，虽然按照上述决议，它应该在此次发布周期内完成它。
问题在于，dpkg 不了解合并 /usr ，因此它不能明白一个在/bin 安装文件的软件包和一个在 /usr/bin 安装同名文件的软件包实际上是安装同一个文件。这在各种极端情况下会导致严重的问题。
目前，合并 /usr 是依靠软件包 usermerge 完成的。该软件包在其 postinst 脚本中执行文件系统操作，但并不能规范化 dpkg 对文件系统布局的理解。
他建议，dpkg 应该了解合并 /usr 过渡中涉及到的各种别名，并且能够将它自己的数据库中所安装的文件系统路径规范化，这样它就不会混淆安装在 /bin 和 /usr/bin 中的文件（其他受影响的路径也是一样）。
正如同 debian-devel 邮件列表上讨论的一样，仍有一些具有挑战性的问题需要解决，特别是在引导新系统的时候。目前已经进行了许多工作，使 Debian 可以纯粹通过安装软件包来启动，而不需要在软件包安装之外进行特殊的文件系统操作。然而，目前还不清楚这在合并 /usr 的文件系统中将如何工作，特别是如何创建与合并 /usr 相关的符号链接，并告诉 dpkg 它们的存在。
争论
放弃合并 /usr 过渡
正面论点
Adam Borowski 建议放弃合并 /usr 过渡。
他指出，合并 /usr 过渡首先由 Solaris 开始，其后由密切关注前者行动及试图在系统之间共享 /usr/的 Red Hat 推动。前一个理由对 Debian 是不现实的，而后一个设想在十年前就已经被放弃了，并且已经被其他方案所取代。因此，对于合并 /usr 过渡，是谈不上跨分发兼容问题的。
目前，进行与不进行合并 /usr 过渡的系统都存在，因此完成或放弃这一过渡的难易程度是相似的。 除了原来的状况能够很好工作外，新的方案已经耗费了许多开发人员很长时间的设计工作，而且目前没有看到彻底的解决方案。
反面论点
Russ Allbery 反驳说，与 Red Hat 的兼容性（特别是在 Debian 系统上运行用于 Red Hat 系统的软件，反之亦然）是跨分发兼容问题。
事实上，Debian/Ubuntu 和 RedHat 衍生产品之间的跨分发兼容性可能是目前 Linux 生态系统中受影响的系统或软件包数量最多的跨分发兼容性问题。在进行和不进行合并 /usr 的系统之间的路径混乱并不经常出现，但它确实出现了，因为程序的路径被硬编码在各种人们想要复制的东西中（可能最明显的是#！ 路径，但不仅仅如此）。
完成或放弃这一过渡的难易程度并不是近似的，因为问题的复杂性并不是由对系统数量的统计所决定的。例如，现在有一些在完成了合并 /usr 后的 Debian 系统上创建的用户程序，它们具有硬编码的合并 /usr 后的路径，这些文件在合并前是在 /bin 或 /lib 中，如果我们撤销合并 /usr ，它们将会崩溃。同样的问题并不适用于完成合并 /usr 过渡的情况，因为那时涉及到的两个路径都是别名，这些程序将继续工作。
他指出，目前的 Debian 系统看起来正处于半成品的过渡期中，有些 Debian 系统是以一种方式配置的，有些则是以另一种方式配置的，我们必须花特别的精力来确保我们不会在某些系统上构建出损坏的软件包，这并不是一个可以接受的状态。
虽然这一工作显然需要修改 dpkg ，而且还需要对系统启动进行精确的设计，使 dpkg 进入正确的配置，但这一工作是值得的，它至少能够得到以下好处：
- 与 Red Hat 及其衍生产品相同的文件系统布局
- 每个人都可以不再关心
/bin和/usr/bin，以及/lib和/usr/lib等等之间的区别（这些区别多年来实际上并不重要）
据称，Guillem 已经写了一个旨在还原 usermerge 所带来的变化的工具，但该工具并不能解决上述硬编码合并 /usr 后的路径的程序将会崩溃的问题，而这个问题甚至可能涉及任何已经安装 usrmerge 软件包的系统上用户开发的软件。
他相信，目前的半成品过渡是一种特别讨厌的技术债务形式，会为 Debian 的未来发展带来严重的问题，迫切需要加以解决。
强制安装 usrmerge 软件包
正面论点
Luca Boccassi 建议，将usrmerge 软件包作为（伪）必需品，并强制在所有地方安装它，可以迅速而简单地完成过渡。他指出，该方案已经在去年被 Canonical 所采用；从采用它的 Ubuntu 21.10 和即将到来的 22.04 LTS 中将近 6 个月的测试结果来看，没有出现任何重大问题，并且行之有效。在近几年的 Debian 的两个版本中，安装该软件包也一直是全新安装和新 debootstrapped 系统的默认行为。在 Launchpad 中，涉及到该软件包的新 bug 只有几个，而且这些 bug 似乎都仅仅是“与遗留文件发生冲突，清理后重新运行，问题解决了”，几乎没有影响发行版的糟糕的 bug。
他指出，如果这个解决方案适用于更受欢迎、有更广泛的安装基础和更大的企业部署数量的 Ubuntu，那么没有理由不能适用于 Debian。
反面论点
Russ Allbery 反驳说，在不修改 dpkg 的情况下继续前进，意味着基本上是在永久地接受一种状态，即把不正确的信息输入软件包管理器。有些文件在 /usr/bin 中，但 dpkg 认为是在 /bin 中。在一些极端情况下，dpkg 在这样的系统中会做完全错误的事情（特别是涉及到改变软件包中的文件路径时），如果让事情处于这种状态，那将会永远地接受微妙的软件包管理错误的风险。这实际上是故意制造数据不一致的问题，并希望它们不会在未来的某个时候表现为错误，对于像软件包管理器这样重要的组件来说，风险太大。
在更实际的层面上，他认为，Ubuntu 目前被屏蔽在这个决定的影响之外，因为 Debian 还没有完成 usrmerge 的过渡,因此相关的文件还没有被移动。正因如此，他认为 Ubuntu 的经验并不像它看起来那么有说服力。
维护者问题
Luca Boccassi 的质疑
Luca Boccassi 对 Russ Allbery 的意见表示怀疑，他指出，自从 2019 年 Debian Buster（Debian 10）发布以来，安装usrmerge 软件包就已成为默认的行为，而“不移动的文件”的决定只发生了几个月时间，它无法决定解释之前几年间发生的事情。
在过去的几年中，许多人都说过很多次他们会“正确地解决这个问题”。然而，最终这并未发生，原因很简单，因为受影响的软件包维护者不仅不愿意为此工作，而且从一开始就公开反对整个提案，迄今为止，这一点并未改变。当然，这完全是他的权利；Debian 的核心准则之一就是不能强迫任何人去做他们不愿意做的事情。
然而，如果每个软件包的维护者都被允许有效地否决技术委员会的决议，那么实际上最终不会得到如何成果，最终的结果就是分发将会停止发布。
综上所述，他认为，在技术委员会已经通过多次投票明确了决议后，目前所进行的安装usrmerge 软件包的方案是最佳方案。
关于维护者态度的讨论
Raphaël Hertzog 提及，虽然技术委员会最近禁止将文件从/{bin,lib,sbin} 移动到 /usr/{bin,lib,sbin} ，但他们说应该在解决了这些迁移问题之后再做。他个人认为，虽然 Guillem 不是很合作，但必须创建 dpkg 的一个补丁并让 Guillem 接受，以最终解决 dpkg 层面的问题。
Luca Boccassi 则怀疑说，鉴于维护者从原则上反对这一提案，Debain 实际上必须强迫维护者接受一个他不想要的补丁，并强迫他在之后维护它。这既不正确也不公平，当然，一个维护者可以否决技术委员会的决议也是不正确的，因此他认为唯一现实的解决方案是不涉及改变 dpkg 的方案。
Russ Allbery 补充说，据他所知，Guillem 也反对强制安装 usrmerge 软件包的方案，这可能是因为他认为这一点在 dpkg 中并不支持。他相信，Debian 的长期目标（无论是否有意为之，在长期内都有可能发生）是所有目前在 /bin 和 /lib 中的文件都将转移到 /usr/bin 和 /usr/lib 中，因为每个人最终都会采用合并 /usr。这尚未开始，特别是对于广泛安装的核心软件包，这就是引发所有问题的原因。
参阅
邮件列表上的相关讨论：