LWN：Debian是否要干掉which？
关注了就能看到更多这么棒的文章哦～
Debian's which hunt
By Jonathan Corbet
October 28, 2021
DeepL assisted translation
https://lwn.net/Articles/874049/
人们通常也不会因为看到大概一页那么长的 shell 脚本而感到愤怒，哪怕是盛产喷子的互联网上也不太会有这种情况。但是 Debian 很特别，它对 which 这个命令的命运就进行了长时间的讨论，并且已经提到了 Debian 技术委员会来继续争议。对一个这么小的、连标准工具都算不上的命令给予了这么多关注，这充分让我们看到了 Debian 的管理方式，还有传统与标准之间的交互。
which 命令就是在当前的搜索路径中找到一个可执行程序，并打印出结果：
$ which nethack
/usr/bin/nethack
这个长期以来一直存在的工具经常被人们用在命令行中来找到某个程序的二进制文件位于什么地方。有些脚本也出于类似的原因而使用 which 命令，或者也会用来确定某个指定程序是否存在。对于许多用户来说，这个命令早已被植入了肌肉记忆，在需要时条件反射般地就敲了出来。
尽管如此，which 其实从来不是这些类 Unix 系统上的标准化组件（standardized component）。POSIX 中没有要求一定要有 which 命令。因此，which 就有了许多种实现，每一种都有一些独到之处。例如许多发行版都采用了 GNU 版的 which 命令，它的特点是有非常多的命令选项。FreeBSD 也有它自己的版本。一些 shell 也会把 which 实现称为一个内置命令。Debian 还另外提供了一个版本，就是上面提到的大概一页长的 shell 脚本的形式，这是 debianutils 软件包的一部分。
在 2020 年 8 月，Erik Gustafsson 注意到 FreeBSD 版本的 which 支持一个 -s 标志，可以用来消除 print 输出，并根据被查询程序是否存在来给出不同的返回值。他认为这个功能在 Debian 中会很有用，于是就提供了一个添加该功能的 patch。接下来，关于 which 的价值以及 Debian 版本的 which 是否应该增加更多功能的讨论就此开始了。其中一方是 Debianutils 的共同维护者 Clint Adams，他认为应该从该软件包中删除 which 命令。
转眼到了一年之后，Boyuan Yang 发现在 Debian 的 unstable 发行版中，which 命令现在打印了一个废弃（deprecation）警告，说 which 今后就不会存在了。这导致很多人感到惊讶（以及许多请求要求得撤销这一改动），原因有很多，首先是许多用户确实希望要用 which。事实证明，许多 Debian 软件包的构建脚本中也使用了 which。此外，这里打印出来的 warning 信息导致一些软件包的构建过程被破坏了。此时 Adams 身上的压力开始增加，人们要求要撤销这个决定。
Adams 有很多理由可以说明应该从 debianutils 中删除 which。受 POSIX 标准所保护的正确的寻找可执行程序的方法是 command -v，确实大多数 shells 中都带有了这个命令。Adams 说，"如果一个标准的 POSIX 工具可以做得更好，肯定没有人愿意让自己的软件包依赖于 'which' 命令"。鉴于 which 有很多变种，每个都有自己的做法，因此把某个版本放在一个标有 "essential" 的软件包中（这就意味着它必须得安装在每一个 Debian 系统上）就是没有意义的。Debian 开发者参考手册曾经建议在维护者的脚本中使用 which，但该建议在 2018 年被删除，转而使用 command -v。因此，亚当斯认为，which 命令肯定不是必须要的。尽管 Debian 提供了这个命令，但它也不应该成为 essential 软件包的一部分。
最后，Adams 认为，关于 which 的未来，有几条路可以走，但是没有一条路可以让所有人满意。在他看来，他所选择的道路是最好的一条：
另一条道路就是为人们建立一个方便的方式来让他们获得他们想要的东西，并把我自己从这个过程中摘出来。这就是我之前尝试在做的。现在，只要有人通过选举愿意来继续维护这些内容，并且 FTP 团队也允许这些 which 命令进来，那么用户就可以直接安装和使用 GNU 版本、*BSD 版本、busybox 版本、rewrite-it-in-rust 版本、或者任何其他的人们可以想到的版本的 which 命令。我依然认为这些做法都是毫无意义的，但这并不重要，因为我并没有妨碍其他人对 "which" 命令的过于神化的追求。
虽然大多数 Debian 开发者似乎并不反对将 which 从 debianutils 包中移出去的这个优雅想法，但也有许多开发者们并不同意。正如 Wookey 所说的，这种改动如果做得更加谨慎一点的话，就可以避免现在看到的许多问题：
如果有一个恰当的过渡计划的话，我就甚至根本不会注意到这一点。用一个 which 来取代另一个 which，没有什么东西会无法继续工作了。这就是我所期望的在 Debian 上应该发生的事情。我们一般都很擅长这么做，这也是大家使用该发行版的一个重要原因。
9 月中旬，Adrian Bunk 将此事提交给技术委员会，要求以多种方式否决 Adams 之前的决定。具体来说，他要求需要确保 which 是由一个 essential 软件包所提供的（他没有说是哪一个），不可以打印 deprecated 这个 warning 信息，而且也不可以通过 "alternatives" 机制来提供。"alternatives" 是 Debian 用来允许用户选择一个命令的多种实现版本中进行选择的一种方式。考虑到 which 存在那么多种版本，这个机制似乎应该很适合才会。Bunk 说这不是一个好的选择，因为如果维护者的脚本在提供该命令的软件包完全配置好之前就试图使用 which 的话，就无法正常进行升级了。
Bunk 还向技术委员会提出了另外两个意见，但这两个意见都没有引起那么大的反响。一个是要求 debianutils 必须继续提供 tempfile，这也是被砍掉的功能。另一个是要求 debianutils 的程序不能被移到 /usr。最后一个要求与 Debian 内部正在进行的 /usr 合并过渡的另一场大辩论有关。委员会在 10 月 18 日就这个问题发布了一个冗长的裁决，基本上是说软件包们在 Debian 12 之前都不要指望看到合并过的 /usr 目录了。
技术委员会的早期讨论似乎很快就达成了一个共识，那就是 debianutils 必须继续提供 which，至少要在其他 essential（或 "transitively essential"，意思是 essential 软件包所依赖的软件包）软件包提供了 which 命令的支持之前。不过，在 deprecated warning 这个问题上存在分歧。虽然大多数委员会成员似乎想要求删除，但 David Bremner 不同意："我不认为人们真的应该期望 which(1) 命令永远不向 stderr 进行打印输出"。他说，尽管这个警告很烦人，也不至于达到推翻维护者决策的程度。
因此，10 月 20 日提交给委员会的投票就是用来裁决这个分歧的。它要求 debianutils 暂时必须继续保留 which，但让委员会成员选择是否要求删除这个 warning。在讨论到使用哪种 which 实现时，并没有进行强制要求，而是由相关的开发者来决定如何管理这里的过渡过程。该投票也确实授权保留了 tempfile，并含有不将文件移至 /usr 的说法，这也与 10 月 18 日的裁决一致。
在随后的投票中，两名成员（Bremner 和 Elana Hashman）投票赞成该决议，但不用删除 deprecated 这个 warning 信息。而所有其他成员都赞成整个决议。因此，该决议得以通过，Adams 的决策被撤销了，which 暂时保留在 debianutils 中，不带有 warning 信息。如果能找到另一个 essential 软件包来适合放置 which 命令（还有 tempfile），那么在 Debian 12 发布之前，它们应该就会从 Debianutils 中过渡到新的软件包去了。
所有这些，看起来都像是在对一个小小命令的过度反应，而事实上也确实是这么回事。但这也正展示了 Debian 项目希望这类改动该如何进行。Debian 开发者对他们的软件包几乎有绝对的控制权，但是当某个开发者在行使这种控制权时，如果出现对整个发行版造成损害的情况，则会有相应的机制来进行干预。这就是 Debian 如何在三十年的时间里如何做到让数百名具有独立思考能力的开发者能朝着同一个共同的目标来努力的。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～