Debian's which hunt

Welcome to LWN.net

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!

One does not normally expect to see a great deal of angst over a one-page shell script, even on the Internet. But Debian is special, so it has been having an extended discussion over the fate of the which command that has been escalated to the Debian Technical Committee. The amount of attention that has been given to a small, nonstandard utility shines a light on Debian's governance processes and the interaction of tradition with standards.

The which command will locate an executable program within the current search path and print the result:

    $ which nethack
    /usr/bin/nethack

This long-present tool is often used at the command line to locate the binary for a program; scripts also use it for similar purposes, or to determine whether a given program is available at all. For many users, which has long been baked into muscle memory and is used reflexively at need.

For all that, which is not a standardized component on Unix-like systems; POSIX does not acknowledge its existence. For that reason, among others, there are a number of implementations of which, each differing in its own special ways. Many distributions ship the GNU version of which, for example, with its characteristic long list of options. FreeBSD has its own version. Some shells also implement which as a built-in command. Debian ships yet another version, in the form of the aforementioned one-page shell script; it is part of the debianutils package.

In August 2020, Erik Gustafsson noted that the FreeBSD version of which supports a -s flag that suppresses the printed output and sets the exit status based on the existence of the queried program. He thought that feature would be useful in Debian, and helpfully provided a patch adding that feature. Thus began the discussion of the value of which and whether Debian's version should gain more features; at one point Clint Adams, the co-maintainer of debianutils, opined that which should be removed from that package.

Fast-forward to one year later, and Boyuan Yang observed that the which command in the Debian unstable distribution now prints a deprecation warning saying that which is going away. This resulted in a fair amount of consternation (and requests for a reversion of the change) for a number of reasons, starting with the fact that many users simply expect to have which available to them. It turns out that a number of build scripts for Debian packages use which as well; as an extra annoyance, the printed deprecation warning breaks the build process for some packages. The amount of pressure applied to Adams to restore which began to increase.

Adams has a number of reasons for wanting to remove which from debianutils. The POSIX-blessed way of finding an executable program is command -v, which is consequently built into most shells. Given the standard alternative, Adams said, "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job". Given that there are numerous variants of which, each with its own advocates, it makes little sense to ship one version in a package marked "essential" (meaning that it must be installed on every Debian system). The Debian Developer's Reference manual once suggested using which in maintainer scripts, but that suggestion was removed in 2018 in favor of command -v. So the which command, Adams argued, is certainly not essential; even if Debian ships it at all, it should not be part of an essential package.

In the end, Adams argued, there are several paths that could be followed regarding which, none of which can please everybody. The path he has chosen is, in his opinion, the best one:

Another is to build a runway for people to get what they want and remove myself from the equation. This is what I have attempted to do. Now, provided anyone elects to maintain them and the FTP team allows them in, users will be able to install and use GNU which, *BSD which, busybox which, rewrite-it-in-rust which, or whatever should float someone's boat. I can think all of this is pointless, and it doesn't matter, because I am not impeding anyone else in their pursuit of which(1) apotheosis.

While most Debian developers do not appear to be opposed to the idea of gracefully moving which out of the debianutils package, many of them disagree with how that is being done. As laid out by Wookey, this change, if done with a bit more care, could avoid many of the problems that are being seen now:

A proper transition plan would mean that I would never even notice this. One which would replace another and nothing would break. That is the sort of thing I expect to happen in Debian - we are generally good at this stuff, and it's a big reason for using the distro.

In mid-September, Adrian Bunk took the matter to the Technical Committee, asking that Adams be overridden in a number of ways. Specifically, he requested a decision that which be provided by an essential package (he didn't say which one), that it not be allowed to print deprecation warnings, and that it not be provided via the "alternatives" mechanism. "Alternatives" is how Debian allows users to choose between multiple implementations of a command; it would seem to fit the bill here, given the number of versions of which that exist. Bunk said that was not an option because it could break upgrades if a maintainer script tries to use which before the package providing it is completely configured.

Bunk's message also asked for two other opinions from the Technical Committee, neither of which generated as much heat. One was to mandate that debianutils must continue to provide tempfile, which is also on the chopping block; the other was that debianutils programs cannot be moved into /usr. That last request ties into another big debate within Debian over the ongoing implementation of the /usr merge transition. The committee issued a lengthy ruling on that subject on October 18, essentially saying that packages cannot count on a merged /usr until after the upcoming Debian 12 release.

Early discussions within the Technical Committee seemed to lead to a relatively quick consensus that, indeed, debianutils must continue to provide which at least until some other essential (or "transitively essential", meaning that an essential package depends on it) package provides it. There was a disagreement over the deprecation warning, though; while most committee members seemed minded to mandate its removal, David Bremner disagreed: "I don't think people are really entitled to expect which(1) to never print to stderr". Even if the warning is annoying, he said, it doesn't rise to the level where overriding a maintainer is justified.

So the ballot that went to the committee on October 20 reflected that disagreement. It mandates that debianutils keep which for now, but gives committee members the choice of whether they would require the warning to be removed. There is no mandate when it comes to the use of alternatives; it is up to the relevant developers to decide how the transition is to be managed. The ballot does mandate keeping tempfile and includes the language on not moving files to /usr, which is consistent with the October 18 ruling.

In the resulting voting, two of the members (Bremner and Elana Hashman) voted for the resolution without the removal of the deprecation warning; all other members were in favor of the whole thing. The resolution thus passed, Adams has been overridden, and which stays within debianutils — without the warning — for now. Assuming that a home for which (and tempfile) can be found in another essential package, though, the path is clear for them to transition out of debianutils before the Debian 12 release.

All of this may seem like a big fuss over a tiny program, and that is indeed what it is. But it is also a statement of how the Debian project wants changes like this to be made. Debian developers have nearly absolute control over their packages, but there are mechanisms in place to intervene when one developer exercises that control in a way that appears damaging to the distribution as a whole. This sort of whichcraft is how Debian has managed to keep hundreds of independent-minded developers working toward a common goal for the better part of three decades.

---

(Log in to post comments)