[Followups to debian-policy, please] On Tue, Aug 15, 2000 at 11:22:11PM -0500, Manoj Srivastava wrote: > I think that some people are espousing non-compliance with the > standards. Is that what we want to do?
The FHS exhaustively explains the difference between compatibility and compliance. I note that the Debian policy manual says that all installed files and directories "must comply" with the FHS, rather than "must be compatible" with the FHS. Let this message serve as policy proposal that we change the wording of section 3.1.1 from "must comply" to "must be compatible". This change needs to be made irrespective of any consensus (or lack thereof) on the issue moving binaries from (/usr)?/sbin to (/usr)?/bin, because we continue to carry around relics of non-FHS-compliance (such as /var/state) that may take quite some time to dislodge. (Witness the /usr/share/doc migration.) Furthermore, the footnote following the URL of the FHS should probably be deleted, since FHS 2.1 is no longer in draft status. > Steve> OK, how about moving everything into /bin except what FHS > Steve> specifically says should be in /sbin? Section 3.10[0] > Steve> identifies the following specifically to be located in /sbin: > > Sounds like a cop out. We are acknowledging that we can no > longer come to a consensus on this, and we are punting on > this. Actually, it may be closer to saying we really don't like sbin, > and we move everything out of there, except that we also want to be > FHS compliant, and let just tose programs stay in. I can agree with either interpretation, though I disagree with your characterization of the former as a "cop out". The traceroute argument comes up over and over again. The defenders of the status quo have no defense for the inconsistency between having one traceroute tool in sbin and a different one in bin. Rather than having one of the programs move, they just tell people to change their $PATH. This does not indicate to me the slightest motivation to "extend the reasoning of the FHS". The FHS team has given themselves a mandate to sort these issues out. Let them. Why should we argue about whether a certain binary goes in one directory or the other when it's a much bigger part of their mission statement to make that decision than ours? FHS is an open standards group, more to the point, so Debian developers who feel passionately about such things can join it and carry on their flamewars there. > I think we should either > a) categorize the programs, by extending the reasoning of the FHS, > and I have not yet lost hope of our ability to reach a rough > consensus, I think it's the FHS's job to delimit its own reasoning. There are places where it defers to vendors. > b) decide that the sbin idea is silly, and that's that (we can > symlink /sbin to /bin) Well, that's my personal feeling, but I don't think one needs to feel this way to know that the appropriate place for traceroute is not sbin. > I think we may be truthfully accused of losing touch with the > generic user out there. I think the generic user neither knows nor cares about the distinction between bin and sbin. There's also no reason to fence him off from harmless and even useful commands. Quoting the FHS: Deciding what things go into "sbin" directories is simple: If a normal (not a system administrator) user will ever run it directly, then it should be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path. Note: For example, files such as chfn which users only occasionally use should still be placed in /usr/bin. ping, although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and should live in /bin for that reason. -- G. Branden Robinson | Software engineering: that part of Debian GNU/Linux | computer science which is too difficult [EMAIL PROTECTED] | for the computer scientist. http://www.debian.org/~branden/ |
pgpjfu0lVrcA4.pgp
Description: PGP signature