Sam Hartman <hartm...@debian.org> writes: > My problem with (b) is that I value interfaces and that especially for > /bin/sh I do think that /bin/sh is more portable as an interface path > than /usr/bin/sh.
To be clear, I personally agree with this, and I am sure that I will use /bin/sh until the end of time, even if every extant UNIX system decides to create a /usr/bin/sh alias for it (one way or the other). But from an interface perspective, I think it adds some clarity to think of it this way: When people started merging /bin and /usr/bin, they added a new /usr/bin/sh interface for invoking the Bourne shell. They may not have intended to do this, but that's what they did, and there was nothing inherent in the system to prevent people from using that interface. So people started doing so. I'm sure that I'm not the only one who has encountered #!/usr/bin/sh scripts in the wild, usually because the person who wrote the script was using some Red Hat or Fedora distribution and didn't really think about it. Either they were used to the /usr/bin pattern from Perl and Python or they ran "which sh" and, as Bill points out, that returns /usr/bin/sh, etc. Up until now, those scripts didn't work on Debian systems, which caused some minor annoyances. Now they do. What has essentially happened given the number of distributions that have done /usr-merge is that Linux has added /usr/bin/sh as a new interface that is interchangeable with /bin/sh, and now nearly every current Linux system you run across will also support that interface. This is annoying for UNIXes that don't support that interface (I don't know what the BSDs are doing, for instance), but it's fairly invisible to users unless they care about portability to non-Linux systems. I care about portability to non-Linux systems in at least some situations, but a lot of people don't. (Incidentally, this interface argument is also why I have some nit-picks about the wording of Luca's proposed patch, because the guarantees in Policy apply specifically to /bin/sh and /usr/bin/sh, not to, say, /usr/local/bin/sh or /usr/xpg4/bin/sh or whatever. This is an admittedly very minor point.) > I care a lot that we use /bin/sh in our documentation and examples > (especially in policy). I agree with this. If we write example scripts, I think they should use #!/bin/sh. I don't think my (b) proposal is arguing against that; (b) says that both paths work and you can use either of them, and Policy will chose to use /bin/sh at least for the time being because, well, I'm one of the Policy Editors and I care about things like that. :) I think Policy would only use /usr/bin/sh in documentation and examples if we adopted (c), which based on the discussion so far seems unlikely. > I care a lot that we point out that the reality of the situation is > people will see other paths. This is the part that I'm really focusing on at the moment, because I think it's what people are really asking and what directly addresses the concern about bug reports asking maintainers to switch from /usr/bin/sh to /bin/sh. If Debian is going to contain scripts that use /usr/bin/sh, this is a change and we should say so explicitly. Bill pointed out precisely the way that I expect this to happen: a lot of packages use PATH searches in their build systems to find common tools, and although I think this is ill-advised, some of them do that for sh (mostly because of old Solaris breakage). As soon as the buildds are /usr-merged, those packages are going to start using /usr/bin/sh instead of /bin/sh because it's first in the PATH, assuming the buildds use the same PATH setup as /etc/login.defs (I don't know if this is the case). And the question is do we tell maintainers that they should fix this, or do we accept that it will happen and not worry about it? I personally probably would find a way to force /bin/sh somewhere because I am a perfectionist, but it requires overriding the upstream build system and maintaining that code going forward and a lot of maintainers aren't going to want to bother. I think Policy should provide some guidance to both maintainers and bug reporters here about what we expect. > At least for things traditionally in /bin I do not want to encourage > those other paths, but I also don't think it is often a good use of > project resources to "fix" those other paths. Precisely. To me, that's the heart of the (b) position, although people advocating for (b) are going to vary from "prefer /bin" to "prefer /usr/bin" and (b) is sort of inherently a compromise position about what we're going to *do* among people who have different preferences about style. > In some cases (for example what version of a path autoconf detects), I > think that patching individual packages to detect a particular path > would be net harmful. Yeah, it sounds like you're thinking of exactly the case I was thinking of. > So I want to argue for (a) with no enforcement mechanism in packages. > 1) Policy should encourage /bin paths for binaries traditionally in > /bin. (At a minimum I'd like to see this for /bin/sh and /bin/bash). > That at most makes it a minor bug if you don't follow that > encouragement. I think this is the only part of your proposal that I have qualms about, because I agree with Luca that people would use such encouragement to file bugs about it, and I'm not sure we want to encourage those bugs. It may not matter a lot because the bugs will probably exist anyway, but I know that putting things in Policy can sometimes raise the temperature of even minor bugs. I'd be happy to make some sort of statement in the section about shell scripts that /bin/sh and /bin/bash are the traditional paths and will work even if the script is copied to some non-Debian system, but I'm reluctant to issue Policy advice that one therefore should use those paths. But I could be convinced as long as it's just advice, not a should. (But, again, Policy is not a style guide.) > 2) The examples in policy should use the standard interface paths. > (This is the thing I care most about). I agree with this and I'm not seeing any disagreement in the discussion so far. > 3) I'd like to see policy point out that /usr/bin paths will end up > being used, and packages SHOULD work regardless of which path is used. This is the thing that I care the most about and would like to say explicitly somewhere in Policy, even though that's beyond the scope of Luca's original report. I don't think Policy says anything about /usr-merge at all right now, and once the buildds are merged and all Debian systems relevant to unstable development are /usr-merged, we probably should. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
